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EXECUTIVE  SUMMARY 


This  executive  summary  provides  the  essence  of  the  results  of  Engineering  Demonstration- 1 
(ED-1),  which  was  conducted  17-20  October  1995.  The  report  for  Engineering  Demonstration- 1 A 
(ED-IA),  which  was  conducted  14-16  November  1995,  will  be  published  in  a  separate  document. 
ED-1  was  conducted  on  both  the  Advanced  Communication  Technology  Satellite  (ACTS)  Asynchro¬ 
nous  Transfer  Mode  (ATM)  Internetwork  (AAI)/Advanced  Technology  Demonstration  Network 
(ATDNet)  and  the  Defense  Simulation  Internet  (DSI)  over  a  period  of  2  days.  The  Synthetic  Envi¬ 
ronment  (SE)  portion  was  done  on  Day  1  over  the  AAI/ ATDNet  between  the  Naval  Command,  Con¬ 
trol  and  Ocean  Surveillance  Center  (NCCOSC)  Research,  Development,  Test  and  Evaluation 
(RDT&E)  Division  (NRaD),  the  Institute  for  Defense  Analyses  (IDA),  the  Defense  Advanced 
Research  Projects  Agency  (DARPA),  the  Applied  Research  Laboratories  :University  of  Texas 
(ARLrUT),  and  the  Topographic  Engineering  Center  (TEC).  The  ED-1  Scenario  was  run  on  Day  2 
over  the  DSI  between  NRaD,  IDA,  What  If  Simulation  System  for  Advanced  Research  and  Develop¬ 
ment  (WISSARD),  and  the  United  States  Atlantic  Command  (USACOM)  at  the  Joint  Training  and 
Analysis  Simulation  Center  (JTASC).  The  ED-1  Scenario  Synthetic  Forces  (SF)  participants 
included  Navy  Synthetic  Forces  (NSF),  Marine  Corps  Synthetic  Forces  (MCSP0>  Command  Forces 
(CFOR),  Intelligent  Forces  (IFOR),  Air  Force  Synthetic  Force  (AFSP^,  and  Army  Synthetic  Forces 
(ASF). 

The  Synthetic  Environment  demonstration  portion  of  ED-1  successfully  demonstrated  the  follow¬ 
ing  environmental  effects: 

•  Illumination  flares,  signal  flares,  and  signal  smoke; 

•  Dynamic  time-of-day; 

•  Wind  effects  (velocity  and  direction); 

•  Concertina  wire; 

•  Battlefield  smoke  and  obscurants; 

•  Minefield  breaching; 

•  Anti-tank  ditch  breaching; 

•  Dust  storm,  rain,  fog,  haze; 

•  Pre-emplaced  survivability  positions  and  obstacles; 

•  Multistate  objects  (bridges/buildings). 

The  Synthetic  Forces  demonstration  portion  of  ED-1  successfully  demonstrated  the  following: 

•  Five  Ships — maneuvering  and  damage; 

•  Sensors  and  weapons  functionality; 

•  18  new  Marine  Corps  entity  types; 

•  Embark/Disembark  functionality; 

•  Suppressive  fire; 

•  Attachment; 


•  IFOR — ^Fixed  Wing  Aircraft  (FWA)  Defensive  Air,  Close  Air  Support  (CAS)  combined  strike, 
Rotary  Wing  Aircraft  (RWA) — armed  reconnaissance,  attack; 

•  IFOR  FWA  reacted  correctly  to  unexpected  interactions ; 

•  Forward  Air  Controller  (FAC); 

•  Bridges  were  destroyed,  providing  a  barrier  to  ground  vehicles; 

•  Tanks  deployed  smoke,  changed  speed/formation  when  entering,  leaving  smoke  screen; 

•  Forward  Observer  (FO) — ^Detected,  classified,  and  reported; 

•  Company  team  commander; 

•  Received/sent  Command  Control  Software  Interface  Language  (CCSIL)  messages; 

•  Planned/replanned  missions. 
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1.  INTRODUCTION 


Section  1  describes  the  purpose  of  this  document,  discusses  the  project’s  background,  and  offers  a 
definition  of  the  data  collection  and  analysis  problem. 

1.1  PURPOSE  OF  DOCUMENT 

This  document  reports  the  results  of  defining,  measuring,  and  analyzing  the  performance  factors 
and  limitations  of  the  interaction  of  Synthetic  Forces,  Synthetic  Environment,  and  advanced  technol¬ 
ogies  over  the  Advanced  Communication  Technology  Satellite  (ACTS)  Asynchronous  Transfer 
Mode  (ATM)  Internetwork  (AAI/ATDNet)  and  the  Defense  Simulation  Internet  (DSI). 

1.2  PROJECT  BACKGROUND 

The  Synthetic  Theater  of  War  (STOW)  is  an  Advanced  Concept  Technology  Demonstration 
(ACTD)  jointly  sponsored  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  and  the 
United  States  Atlantic  Command  (USACOM).  The  objective  of  STOW  is  to  develop  a  synthetic  the¬ 
ater  of  war  combining  virtual  and  constructive  simulation  in  the  areas  of  mission  rehearsal  and  Joint 
Task  Force  (JTF)  training.  The  STOW  program  is  composed  of  a  series  of  engineering  demonstra¬ 
tions  that  will  integrate  Distributed  Interactive  Simulation  (DIS)  technologies  in  preparation  for  joint 
applications  demonstrations.  Engineering  Demonstration- 1  (ED-1)  focused  on  the  integration  of  the 
various  technologies,  with  emphasis  on  engineering  and  analysis. 

STOW  will  significantly  increase  the  scope  of  distributed  interactive  simulation.  Not  only  will  the 
number  of  supported  entities  dramatically  increase,  but  the  richness  of  the  synthetic  environment  will 
be  enhanced  through  the  addition  of  smoke,  dynamic  terrain,  and  weather.  The  introduction  of  com¬ 
mand  forces  (CFOR)  and  Command,  Control,  Communications,  and  Intelligence  (C^I)  simulation 
will  also  increase  the  complexity  of  interactions  and  behaviors.  The  net  result  will  be  large  increases 
in  complexity  and  interdependence.  Information  that  must  be  exchanged  will  also  increase. 

1.3  PROBLEM  DEFINITION 

This  report  addresses  analyzing  test  results  and  collected  data  to  enable  the  project  team  to 
(1)  learn  how  to  best  configure  system  components  for  acceptable  network  and  simulation  perfor¬ 
mance  and  interoperability,  and  (2)  determine  which  performance  factors  are  critical,  how  they  are 
related  to  one  another,  what  the  performance  limits  are,  and  how  the  system  behaves  near  its  limits. 

1.3.1  Evaluate  System  Performance 

A  thorough,  objective  analysis  of  collected  data  and  test  results  enabled  the  project  team  to  objec¬ 
tively  evaluate  system  performance  along  the  path  to  STOW  97. 

1.3.2  Assess  Capabilities,  Status,  Maturity 

Analysis  of  collected  data  and  test  results  provides  a  means  of  assessing  the  capabilities,  status, 
and  maturity  of  Synthetic  Forces,  Synthetic  Environment,  and  advanced  technologies. 
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1.3.3  Risks 


A  thorough,  objective  analysis  of  data  collected  during  ED-1  will  enable  the  project  team  to  avoid 
the  risk  of  repeating  mistakes  during  ED-2  or  pursuing  technology  alternatives  that  show  little  or  no 
promise. 
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2.  DATA  COLLECTION  AND  REDUCTION 


Section  2  describes  data  collection  tools  and  network  configurations  used  in  STOW  ED-1.  It  also 
provides  a  brief  descriptive  summary  of  the  collected  data. 

2.1  TOOLS 

The  tools  used  in  STOW  ED-1  for  data  collection,  reduction,  and  analysis  are  described  below. 

1.  Collection.  The  ACUSOFT  Version  3.0  data  logger  recorded  broadcast  LAN  PDU  traffic. 
NRaD  modified  the  data  logger  to  record  multicast  LAN  PDU  traffic.  WAN  packets  were 
recorded  with  the  UNIX  utility,  TCPDump.  The  Hewlett-Packard  (HP)  Open  View  Network 
Node  Manager,  Version  3.31,  was  used  to  queiy,  read,  and  record  Management  Information 
Base  (MIB)  variables  once  each  minute.  Table  1  lists  and  summarizes  data  collection  tools 
and  techniques. 

2.  Reduction.  Data  reduction  separates  “ground-truth”  information  from  the  raw  data  collected 
during  the  test.  This  section  defines  required  data  reduction  tools  and  techniques.  Table  2  lists 
and  summarizes  required  data  reduction  tools  and  techniques. 

3.  Analysis.  Analyses  were  performed  during  the  actual  progress  of  tests,  and  some  were  com¬ 
pleted  after  the  tests  were  over.  Some  analyses  had  to  be  performed  during  the  test  because  the 
analysis  results  were  needed  in  real  time  for  network  diagnostics  and  troubleshooting.  Table  3 
lists  and  summarizes  analysis  tools  and  techniques. 


Table  1.  Data  collection  tools  and  techniques. 


Manufacturer 

Name 

Version 

Description 

TCPDump 

UNIX  utility  that  reads  and  records  WAN 
packet  traffic  in  binary  data  files. 

ACUSOFT 

Modified  (by  NRaD) 
ACUSOFT  Data  Logger 

3.0 

Reads  and  records  LAN  DIS  PDU  traffic  in 
binary  data  files. 

NRaD 

Test  log  forms 

Records  entity  behaviors  observed  on 

Plan  View  Display  (PVD)  or  “Stealth”  (3-D) 
display  in  real  time,  for  a  qualitative 
analysis  of  simulation  test  results. 

Table  2.  Data  reduction  tools  and  techniques. 


Manufacturer 

Name 

Version 

Description 

NRaD 

(Computer  program) 

Converts  space-delimited  ASCII  files 
written  by  HP  Open  View  into 
comma-delimited  ASCII  files  that  PV-Wave 
can  read. 
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Table  3.  Analysis  tools  and  techniques. 


Manufacturer 

Name 

Version 

Description 

LORAL 

ModStealth 

1.0a 

Provides  real-time,  “Stealth”  (3-D)  display 

Advanced 

of  entity  behaviors  that  facilitates 

Distributed 

qualitative  analysis  of  simulation  test 

Simulation 

results. 

(LADS) 

Analysis  tools  utilized  by  the  different  technology  areas  are  provided  in  the  following  subpara¬ 
graphs. 

2.1.1  Army 

The  analysis  tool  used  by  CFOR  was  an  ACUSOFT  data  logger  located  at  IDA  that  was  used  to 
record  the  CFOR  data  for  later  replay,  as  required.  Handwritten  notes  were  also  recorded  by  a  Sub¬ 
ject  Matter  Expert  (SME),  Scott  Carey.  Mr.  Carey,  a  career  Army  Armor  officer,  retired,  now  work¬ 
ing  at  Logicon  RDA.  The  tools  used  by  Intelligent  Forces  (IFOR)  were  the  ModSAF  Plan  View 
Display  (PVD),  the  Soar  trace  and  interaction  windows,  and  paper  for  taking  notes.  For  Army  SF 
tools.  Simulation,  Training  and  Instrumentation  Command  (STRICOM)  reported  monitoring  tests, 
took  notes,  manually  logged  events  and  activities,  held  discussions  with  operators  and  support  per¬ 
sonnel,  and  filled  out  the  assessment  templates.  Worksheets  containing  all  the  raw  data  are  available 
upon  request,  but  are  not  supplied  in  this  report.  Additional  tools  used  were  data  logger  output  and 
Stealth  video. 

2.1.2  Navy 

The  Navy  Air  and  Air  Force  tools  are  combined  in  paragraph  2.1.4.  For  Navy  (Surface)  Synthetic 
Forces,  all  data  were  collected  at  NRaD  by  K.  Ferguson,  R.  Medved,  W.  Buchanan,  and  B.  Leef  of 
Advanced  Teleconununications,  Incorporated  (ATI).  All  analyses  were  performed  at  NRaD  and  ATI 
by  K.  Ferguson  and  R.  Medved.  The  collection  method  was  to  execute  ED-1  vignettes  and  observe 
entity  appearance,  characteristics,  and  operational  capabilities  on  the  ModSAF  PVD  or  ModStealth 
display.  Entity  appearance,  characteristics,  and  operational  capabilities  observed  were  recorded  on 
data  collection  logs. 

2.1.3  Marine  Corps 

The  analysis  tools  used  by  MCSF  were  the  MCSF  PVD,  ModStealth,  CommandTalk  Inteipreter 
Window,  and  paper  for  taking  notes.  MCSF  personnel  manually  logged  events  and  activities,  and 
engaged  in  discussions  with  Graphical  User  Interface  (GUI)  operators  and  SMEs  (including  repre¬ 
sentatives  from  MITRE,  BMH,  and  ATI),  and  filled  out  assessment  templates.  The  SMEs  were 
Mack  Brewer,  Terry  Tucker,  Tony  Osterman,  Dave  Long,  and  Mike  Olivier.  SMEs  are  retired 
Marine  Corps  officers,  ranging  from  Colonel  to  Major,  with  expertise  in  infantry,  tank  command,  and 
amphibious  track  vehicles. 

2.1.4  Air  Force 

The  Air  Force  Synthetic  Forces  (AFSF)  were  operated  from  the  What  If  Simulation  System  for 
Advanced  Research  and  Development  (WISSARD)  lab  in  NAS  Oceana,  VA.  During  ED-1,  the 
ModSAF  PVD  was  used  to  monitor  the  tests.  Electronic  Systems  Command  (ESC)/AVMW  and 
Loral  Advanced  Distributed  Simulation  (LADS)  personnel  took  notes  and  manually  logged  events 
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and  activities  while  observing  the  PVD.  On  several  occasions,  USAF/XOM  also  provided  person¬ 
nel,  and  their  observations  were  also  recorded.  Problem  Change  Reports  (PCRs)  or  other  types  of 
data  collection  formats  were  not  used  during  ED-1.  Ad  hoc  discussions  were  conducted  to  identify 
problems  with  entity  behaviors  and  possible  solutions  to  be  worked  for  the  next  test  period.  The  data 
logger  was  also  used  to  record  ED-1  activities. 

2.1.5  Synthetic  Environment 

Use  of  ModStealth  and  the  ModSAF  PVD  was  paramount  for  determining  at  TEC,  and  at  all  other 
outlying  sites,  that  the  phenomenology,  weather,  terrain,  and  interactions  between  each  of  these  ele¬ 
ments  appeared  correct  and  that  entity  behaviors  were  correct.  For  example,  all  sites  were  responsi¬ 
ble  for  visually  inspecting  the  correct  visualization  of  the  colored  signal  smoke,  signal  flares,  and 
colored  illumination  flares,  as  well  as  the  types  of  weather  simulated.  Furthermore,  an  entity  must 
behave  and  react  properly  to  signal  smoke  and  react  appropriately  with  reduced  visibilities.  Use  of 
ModStealth  was  essential  to  qualitatively  measure  the  success  of  the  various  SE  elements  demon¬ 
strated  for  ED-1.  In  addition  to  using  ModStealth  to  visually  measure  changes  to  the  Synthetic  Envi¬ 
ronment,  all  sites  would  confirm  changes  in  environmental  parameters  through  the  use  of  ModSAF’s 
Environmental  Editor  on  the  PVD.  For  example,  when  TEC  issued  a  change  in  the  wind  speed  and 
direction  from  the  Environmental  Master,  all  sites  verified  the  exact  values  with  the  ModSAF  Envi¬ 
ronmental  Editor.  If  any  anomalies  had  occurred,  detailed  situation  notes  and  PCRs  would  have  been 
filled  out.  No  data  loggers  were  utilized  until  after  the  unclassified  ED-1,  Day  1,  activities. 

2.2  CONFIGURATIONS 

ED-1  used  the  DSI  and  the  ATM  WAN  (a  union  of  the  Advanced  Communication  Technology  Sat¬ 
ellite  AAI  and  the  ATDNet).  All  LANs  supported  Silicon  Graphics,  Inc.  (SGI)  workstations  con¬ 
nected  by  ethemet,  and  running  ModSAF  to  generate  DIS  entities.  SGI  workstations  were  also  data 
loggers  at  NRaD  and  IDA.  WAN  and  LAN  configurations  are  illustrated  in  Appendix  F.  The  con¬ 
figurations  used  by  the  different  technology  areas  are  contained  in  the  following  paragraphs. 

2.2.1  Army  Configurations 

The  Army  configurations  were  subdivided  into  CFOR,  IFOR,  and  Army  SF.  The  following  para¬ 
graphs  describe  the  configurations. 

2.2.1 .1  CFOR  Configuration.  The  CFOR  team,  which  consisted  of  members  from  Science 
Application  International  Corporation  (SAIC)  (Rob  Calder  and  Rich  Carreiro  provided  Company 
Team  Commander  software  support),  ARL:UT  (Marty  Howard,  Alan  Wolf,  Farrell  Rowe,  and  Mike 
Thompson  provided  Forward  Observer  software  support),  MITRE  (Dave  Seidel,  Mamie  Salisbury, 
Dr.  Lashon  Booker,  Ben  King,  Kurt  Louis,  Jeff  Pace,  and  James  Hughes  provided  systems  engineer¬ 
ing  and  CFOR  Infrastructure  and  CCSIL_SAF  software  support),  Logicon  RDA  (Scott  Carey  pro¬ 
vided  SME  support),  and  NRaD  (Susie  Hartzog  provided  overall  test  coordination  support),  was 
on-site  at  IDA  during  ED-1.  ModStealth  and  an  ACUSOFT  data  logger  were  run  at  IDA  to  support 
all  participants  at  the  IDA  site.  The  following  CFOR  applications  were  each  run  on  SGI  platforms  at 
IDA: 

1 .  CFOR  Commander  of  Company  Team  A/2-67; 

2.  CFOR  Commander  of  Company  Team  C/1-12; 

3.  CCSIL_SAF  GUI; 
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4.  CCSIL_SAF  SIM  (back-end)  for  Company  Teams  A  and  C; 

5.  Forward  Observer  (which  included  its  own  CFOR  Monitor  for  the  display  of  CCSIL  mes¬ 
sages); 

6.  Battalion  (Bn)  Workstation; 

7.  CFOR  Monitor. 

2.2.1 .2  IFOR  Configuration.  The  IFOR  fixed  wing  aircraft  (FWA)  and  rotary  wing  aircraft  (RWA) 
agents  operated  from  WISSARD.  The  RWA  agents  ran  on  a  single  SGI  Indigo2  R4400  workstation 
that  was  shipped  to  WISSARD  from  USC/ISI  for  ED-1.  Once  an  RWA  scenario  started,  the  PVD  on 
this  workstation  was  frozen  to  free  up  as  many  cycles  as  possible  for  the  RWA  agents.  A  second  SGI 
workstation  (a  WISSARD  Indy)  generated  the  OPFOR  for  the  RWA  agents,  and  provided  a  PVD  for 
observing  the  behavior  of  the  RWA  scenarios.  The  FWA  agents  ran  on  two  SGI  Indigo2  R4400 
workstations,  one  shipped  to  WISSARD  from  the  University  of  Michigan  and  the  other  from  WIS¬ 
SARD. 

2.2.1. 3  Army  SF  Configuration.  Assessment  templates  were  used  as  a  data  collection  and  analysis 
technique  for  use  as  an  easy-to-use,  structured  approach.  Each  assessment  template  was  tailored  to 
the  unique  needs  of  each  Service-specific  user  group — ^Army  Land,  Marine  Ops,  Navy,  and  Air 
Force. 

2.2.2  Navy  Configurations 

The  Navy  Synthetic  Forces  (NSF)  were  provided  by  NRaD  (surface  ships)  and  WISSARD  (Navy 
Air). 

1.  The  Navy  Air  Synthetic  Forces  were  operated  from  WISSARD  and  configurations  were 
included  with  the  Air  Force  SF. 

2.  Navy  SF  software  development  and  testing  were  conducted  on  SGI  UNIX-based  computers 
provided  by  the  project  sponsor.  While  development  took  place  on  “pocket”  systems,  testing 
was  usually  conducted  using  a  minimum  of  two  machines,  one  “front-end”  and  one  “back¬ 
end.”  It  was  discovered  during  the  Unit  Verification  Test  (UVT)  that  successful  pocket  SF 
testing  did  not  mean  successful  testing  when  running  separate  front-  and  back-ends,  thus,  all 
future  testing  will  be  conducted  with  separate  front-  and  back-ends.  Integrated  Technologies 
(IT)  testing  was  conducted  in  this  manner  during  the  Test  Continuum  with  remote  sites  over 
the  DSL  During  the  Test  Continuum,  Navy  SF  used  3  front-ends  and  1 1  back-ends  that 
included  a  back-end  for  the  Ordnance  Server  (OS).  System  loading  and  load  leveling  became 
issues  during  the  high-traffic  times  of  ED-1;  further  work  will  need  to  be  done  in  this  area. 
Navy  SF  is  being  developed  by  extensions  and  modifications  to  the  existing  Modular  Semi- 
Automated  Forces  (ModSAF)  applications  (based  on  1.5.1  and  Command  and  Control  Simula¬ 
tion  Interface  Language  (CCSIL)  extensions  1.3.2),  and  by  creating  new  code,  where  neces¬ 
sary,  to  support  requirements  not  included  in  existing  ModSAF  applications.  New  versions 
were  compiled  almost  daily  during  the  Test  Continuum  until  the  code  was  frozen  for  ED-1. 

The  ED-1  version  was  Navy  SF  1.4.0.AC.  The  OS  software,  also  classified,  included  a  Toma¬ 
hawk  flyout  requiring  a  DOS  emulator  to  be  run  on  an  SGI.  Input  to  the  Tomahawk  flyout 
included  preplanned  Tomahawk  missions  run  through  a  validated  mission  planner  at  Dahlgren. 
The  ACUSOFT  data  logger  was  run  to  record  the  DIS  Protocol  Data  Units  (PDUs)  for  later 
playback;  the  LADS  ModStealth  was  run  to  view  the  three-dimensional  world;  and  the  NRaD 
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PVD  was  run  to  verify  two-dimensional  positioning.  The  Navy  SF  TDB  used  was  Southwest 
U.S.  Area  2. 


2.2.3  Marine  Corps  Configurations 

Marine  Corps  Synthetic  Forces  (MCSF)  participated  in  six  phases  of  MCSF  testing  that  included 
stand-alone  MCSF  testing  over  DSI,  and  various  interoperability  testing  with  other  synthetic  forces, 
as  well  as  synthetic  environment. 

1 .  System  and  Supporting  Hardware.  All  the  MCSF  machines  were  running  IRIX  5.3  and  MCSF 
1.5.1  that  are  based  on  ModSAF  1.5.1.  A  total  of  10  machines  were  used,  2  running  Semi- 
Automated  Forces  Stations  (SAFSTAs)  and  8  running  Semi-Automated  Forces  Simulation 
(SAFSIMs).  All  machines  are  located  at  NRaD. 

2.2.4  Air  Force  Configurations 

The  following  information  is  divided  into  information  provided  by  ESC  and  WISSARD. 

1.  ESC.  ESC  configurations  were  as  follows: 

•  Software:  ModSAF  version  2.0; 

•  Equipment:  One  SPARC  20  and  one  Indy; 

•  Location:  Air  Force  was  at  WISSARD  in  NAS  Oceana,  VA,  and  Army  was  at  IDA  in 
Alexandria,  VA; 

•  Terrain:  All  testing  was  done  in  the  Ground  Maneuver  Box  (GMB)  with  the  Army  SF  pro¬ 
viding  ground  targets  for  the  Close  Air  Support  (CAS)  missions.  Dynamic  bridges  were 
targeted  for  Air  Interdiction  (AI)  missions  and  were  contained  in  the  Terrain  Data  Base 
(TDB). 

2.  WISSARD  configurations.  The  specific  hardware  configuration  utilized  at  WISSARD  for  the 
AFSF  and  AirSAF  consisted  of: 

•  Blue  Air:  SGI  R4000  pocket  system  running  WISSARD  Air  SF; 

•  Red  Air:  SGI  R4000  pocket  system  running  WISSARD  Air  SF; 

•  Ground  Targets:  SGI  R4000  pocket  system  running  MCSF; 

•  Data  Logger:  SGI  R4000  (*The  Loral  developed  ModSAF  data  logger  was  used.  See  com¬ 
ments  above  concerning  ACUSOFT.); 

•  Plan  View  Display:  SGI  R4000  (NRaD  2d  PVD  version); 

•  Ordnance  Server:  SGI  R3000  switched  to  SGI  R4400; 

•  Application  Gateway:  SGI  R4400; 

•  IFOR  FWA:  2  x  SGI  R4400; 

•  IFOR  RWA:  2  x  SGI  R4400; 

•  AFSF:  SGI  R4400; 

•  AFSF:  SUN  Sparc  20. 

a.  WISSARD’s  hardware  configuration  was  barely  adequate  for  ED-1 .  This  was  due  to  a 
shortage  of  equipment  that  was  further  hampered  by  requirements  to  perform  additional 
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tasking  over  that  originally  specified  in  June  time-frame.  The  hardware  limitations  high¬ 
lighted  performance  shortfalls  in  some  LAN  systems.  Several  specifics  identified  were  as 
follows; 

(1)  The  lack  of  equipment  at  WISSARD  forced  the  utilization  of  SF  pocket  systems 
where  both  the  SF  Simulation  (SIM)  and  the  Graphic  User  Interface  (GUI)  were 
forced  to  run  on  the  same  machine  as  opposed  to  the  normal  “pairing  of  computers” 
for  the  same  requirement.  Coupled  with  the  level  of  detail  of  the  terrain  for  Area  2 
and  the  GMB,  WISSARD  SGI  R4000  systems  were  often  “overloaded,”  resulting  in 
numerous  “out-of-cycle”  messages  and  much  slower  than  desired  simulation. 

(2)  OS  performance  was  unsatisfactory  when  utilizing  an  SGI  RSOOO-based  computer. 

In  every  case,  this  machine  would  stop  performing  the  server  function  despite  serving 
only  one  instance.  When  switched  to  an  SGI  R4000-based  computer,  it  appeared  one 
OS  machine  could  adequately  serve  two  instances  with  few  problems. 

b.  BMH  Associates  and  the  NAS  Oceana-based  WISSARD  Tactical  Research  Facility  sup¬ 
plied  all  Navy,  Marine  Corps,  and  OPFOR  fixed  wing  and  rotary  wing  air  asset  SF 
requirements  during  ED-1  testing.  This  was  accomplished  through  the  use  of  scheduled 
events  and  cyclic  operations  as  derived  from  an  exercise  Air  Tasking  Order  and  on-call 
events  from  Marine  Corps  and  Navy  Surface  SF  units  operated  from  NRaD. 

c.  The  WISSARD  lab  hosted  its  own  SF  activities  (Navy  and  Marine  Corps  aviation  plus 
CCSIL  testing)  as  well  as  the  AFSF  team  from  Hanscom  AFB  and  WISSARD’s  IFOR 
fixed  and  rotary  wing  team  from  the  University  of  Michigan  and  the  University  of  South¬ 
ern  California’s  Information  Sciences  Institute. 

d.  The  majority  of  events  for  fixed  wing  operations  were  generated  using  AirSAF  (ModSAF 
1.5.1  optimized  for  Navy  and  Marine  Corps  fixed  wing  air  operation  requirements)  sup¬ 
plemented  by  IFOR  agents  flying  SF  vehicles.  RWA  activity  was  generated  mainly  in 
support  of  Marine  Corps  objectives  GMB  terrain  data  base  with  the  one  significant  excep¬ 
tion  being  an  Over-The-Horizon  (OTH)  targeting  mission  utilizing  an  SF  SH-60  helicop¬ 
ter  and  SF  Aegis  passing  CCSIL  messages  between  themselves.  Additionally,  numerous 
IFOR  RWA  missions  were  flown  from  WISSARD  in  the  GMB  to  support  Marine  Corps 
requirements. 

e.  As  a  central  site,  WISSARD  performed  the  following: 

(1)  Carrier  Battle  Group  (CVBG)  air  operations  in  support  of  an  air  tasking  order  similar 
to  one  that  could  be  disseminated  by  a  Joint  Forces  Air  Component  Commander 
(JFACC).  These  consisted  of  operations  involving  Air  Warfare,  Surface  Warfare, 
Strike  Warfare  (STW),  Airborne  Early  Warning  (AEW),  and  Forward  Air  Control 
(FAC)  FWA  missions  and  Surface  Warfare  RWA  missions. 

(2)  Marine  Air  Ground  Task  Force  (MAGTF)  air  operations,  both  FWA  and  RWA,  in 
support  of  amphibious  operations.  Performed  pre-planned  and  on-call  CAS  and  RWA 
troop  transport  missions,  FW  and  RW  Strike  and  RW  escort. 

(3)  Ground  entity  simulation  for  target  utilization. 

(4)  Adversary  air  missions  in  support  of  a  JTF  simulation  exercise.  Provided  offensive 
and  defensive  air,  surface,  and  strike  warfare  missions. 


8 


(5)  IFOR  FW  and  RW  events  that  executed  the  missions  of  a  strike,  CAS,  armed  recon¬ 
naissance,  anti-air  warfare  (AAW),  AEW,  and  aerial  refueling  (AAR)  at  a  much 
higher  fidelity  level  than  possible  utilizing  standard  SR 

f.  Additional  observations.  WISSARD  simulations  were  employed  in  both  the  SW/U.S. 
Area  2  and  GMB  Terrain  Data  Bases  according  to  a  published  Air  Tasking  Order  and  as 
on-call  requests  generated  real  time  during  the  exercise.  WISSARD  used  the  Network 
Time  Protocol  (NTP),  which  received  its  timing  information  from  a  Global  Positioning 
System  (GPS)  sensor  permanently  installed  at  the  site.  An  OS  was  utilized  to  simulate 
valid  flyouts  of  all  weapons  expended  by  AirSAF  entities  that  are  considered  smart  weap¬ 
ons,  i.e.,  requiring  guidance.  Air  Force  Synthetic  Forces  also  worked  out  of  WISSARD 
on  the  equipment  described  above.  Their  missions  were  composed  primarily  of  CAS  and 
will  be  reported  on  by  the  AFSF  team.  WISSARD  and  NRaD  performed  an  OTH  target¬ 
ing  mission  utilizing  CCSIL  to  pass  information  between  synthetic  forces  (SH-60  and 
Aegis)  to  minimize  man-in-the-loop  requirements. 

2.2.5  Synthetic  Environments  Configurations 

Two  scenarios  were  demonstrated  by  Synthetic  Environments  (SE)  from  the  Topographic  Engi¬ 
neering  Center  (TEC)  over  the  AAI/ATDNet  in  an  unclassified  status  for  Day  1  of  Engineering  Dem¬ 
onstration  1  (ED-1).  There  were  four  sites  in  addition  to  TEC  that  participated  or  viewed  these  sce¬ 
narios: 

1.  Naval  Command,  Control  and  Ocean  Surveillance  Center  (NCCOSC)  Research,  Development, 
Test  and  Evaluation  (RDT&E)  Division  (NRaD); 

2.  Institute  for  Defense  Analyses  (IDA); 

3.  Applied  Research  Laboratories  (ARL)  at  the  University  of  Texas  (UT); 

4.  Defense  Advanced  Research  Projects  Agency  (DARPA). 

All  sites  were  using  various  versions,  models,  and  configurations  of  SGI’s  Indigo2s  for  the  Mod- 
SAF  PVD,  and  various  models  and  configurations  of  the  Onyx  for  the  ModStealth.  Only  ARL:UT 
used  an  SGI  Indigo2  for  their  ModStealth  display.  To  test  the  first  scenario,  SE  utilized  the  follow¬ 
ing  hardware  configurations  at  the  various  sites: 

1 .  NRaD  -  One  SGI  Indigo2  PVD  and  one  Onyx  ModStealth; 

2.  IDA  -  One  SGI  Indigo2  PVD  and  one  Onyx  ModStealth; 

3.  ARL:UT  -  One  SGI  Indigo2  PVD  and  one  SGI  Indigo2  ModStealth; 

4.  DARPA  -  One  Onyx  ModStealth; 

5.  TEC  -  Three  SGI  Indigo2  PVDs  and  one  Onyx  ModStealth. 

The  configurations  of  these  machines  follow.  The  first  scenario’s  purpose  was  to  showcase  the 
many  features  introduced  by  SE  to  the  STOW  program.  TEC  served  as  the  weather  master  for  this 
scenario  and  initiated  all  the  events  that  were  observed  by  the  other  sites.  One  SGI  Indigo2  con¬ 
trolled  the  scenario,  and  a  second  Indigo2  with  a  different  persistent  object  (PO)  database  controlled 
the  weather  events.  All  other  sites,  except  DARPA,  used  pocket  systems,  and  all  sites  used  ModS¬ 
tealth  to  view  the  event.  The  first  scenario  consisted  of  four  vignettes: 
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1.  Breaching  exercises,  examples  of  pre-emplaced  dynamic  terrain  objects,  flares  and  smoke,  and 
visualization  of  weather  events; 

2.  Weather  impacts  on  entity  behaviors; 

3.  Survivability  positions; 

4.  Destruction  of  pre-emplaced  dynamic  terrain  objects. 

To  test  the  second  scenario,  SE  utilized  the  following  hardware  configurations  at  the  various  sites; 

1.  NRaD  -  Two  SGI  Indigo2  PVDs  and  one  Onyx  ModStealth; 

2.  IDA  -  Five  SGI  Indigo2  PVDs  and  one  Onyx  ModStealth; 

3.  ARLrUT  -  Four  SGI  Indigo2  PVDs  and  one  SGI  Indigo2  ModStealth; 

4.  DARPA  -  One  Onyx  ModStealth; 

5.  TEC  -  Four  SGI  Indigo2  PVDs  and  one  Onyx  ModStealth. 

The  configurations  of  these  machines  for  the  second  scenario  follows.  The  purpose  of  the  second 
scenario,  called  the  Samarian  Trench,  was  to  integrate  many  of  the  features  that  SE  introduced  to 
STOW,  and  to  demonstrate  that  SE  works  in  a  distributed  environment.  The  Samarian  Trench  sce¬ 
nario  was  divided  into  four  segments: 

1.  Breaching  force; 

2.  Assault  force; 

3.  Overwatch  force; 

4.  Opposing  force. 

TEC  was  the  weather  master  for  this  scenario  and  controlled  the  breaching  force.  As  before,  the 
weather  was  controlled  on  an  SGI  Indigo2  using  a  unique  PO  data  base  number.  The  breaching  force 
used  a  no-sim  front-end  to  control  the  events  and  two  back-ends  to  control  the  entities.  A  three- 
dimensional  view  of  the  scenario  was  accomplished  with  ModStealth  on  an  Onyx.  NRaD  controlled 
the  opposing  forces.  The  opposing  force  used  a  no-sim  front-end  to  control  the  events  and  a  back¬ 
end  to  control  their  entities.  A  3-D  view  of  the  scenario  was  accomplished  with  ModStealth  on  the 
Onyx.  IDA  controlled  the  overwatch  forces.  The  overwatch  force  used  a  no-sim  front-end  to  control 
the  events  and  four  back-ends  to  control  the  entities.  A  3-D  view  of  the  scenario  was  also  accom¬ 
plished  with  ModStealth  on  an  Onyx.  Finally,  ARL:UT  controlled  the  assault  forces.  The  assault 
force  used  a  no-sim  front-end  to  control  the  events  and  three  back-ends  to  control  the  entities.  A 
wire-frame  3-D  view  of  the  scenario  was  accomplished  with  ModStealth  on  an  SGI  Indigo  2. 

2.3  DATA  SUMMARY 

The  data  collected  included  logging  the  exercises  to  tape  using  the  data  logger.  The  data  included 
Simulation  PDUs  and  Entity-State  PDUs,  as  well  as  visual  observations,  and  notetaking  on  perfor¬ 
mance,  interactions,  and  modeling.  The  following  paragraphs  describe  the  individual  technologies 
and  SE  data  summaries. 

2.3.1  Army  Data  Summary 

The  following  paragraphs  describe  the  data  summary  provided  by  the  Army  for  CFOR,  IFOR,  and 
ASF. 
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1.  CFOR.  Overall,  the  participation  of  CFOR  in  ED-1  was  a  success.  ED-1  was  the  first  oppor¬ 
tunity  for  the  CFOR  team  to  demonstrate  CFOR  development  to  the  STOW  community.  Dxir- 
ing  ED-1,  the  CFOR  team  successfully  demonstrated  two  CFOR  virtual  company/team  com¬ 
manders  (SAIC  software)  operating  in  a  tactical  environment  alongside  an  operator-controlled 
ModSAF  company  in  a  virtual  training  exercise.  The  CFOR  company  commanders  received  a 
task  force  order,  parsed  the  order  to  identify  areas  relevant  to  their  respective  company,  con¬ 
ducted  mission  analysis  to  include  Mission,  Enemy,  Terrain,  Troops  available,  and  Time 
(METT-T),  and  developed  courses  of  action  that  they  formatted  into  company-level  CCSBL 
orders.  These  orders  were  then  sent  to  the  task  force  commander  (simulating  a  briefback  pro¬ 
cess)  for  approval.  Once  the  task  force  commander  approved  the  company  orders,  the  CFOR 
companies  executed  these  plans.  From  the  fire  support  point-of-view,  the  FO’s  vignette, 
although  not  complex,  was  considered  successful.  ARL;UT  demonstrated  the  ability  to  pro¬ 
vide  planned  enhancements  and  a  reimplemenation  of  rule  sets  from  their  existing  Fire  Support 
Automated  Test  System  (FSATS)  simulation  to  produce  a  working  When  Ready  Fire  for  Effect 
mission  thread.  Prior  to  ED-1,  the  CFOR  software  developers  were  going  through  extensive 
Situational  Test  Exercises  (STXs)  and  virtual  Field  Training  Exercises  (vFTXs).  Results, 
including  problems  encountered  in  the  STXs,  vFTXs,  and  ED-1,  were  noted  and  are  being 
addressed  by  the  responsible  organization.  Seven  problems  were  identified  in  ED-1.  Two  of 
these  problems  have  been  solved,  and  the  remaining  ones  are  still  being  addressed.  A  detailed 
description  of  the  ED-1  results  is  listed  in  section  3.2.2. 1.  Detailed  STX  and  vPTX  results  are 
provided  in  a  separate  document  that  can  be  obtained  from  NRaD. 

2.  IFOR.  The  Army  IFOR  data  summary  for  ED-1  was  as  follows: 

a.  FWA  Capabilities.  By  the  second  day,  all  missions  were  flown  correctly.  A  total  of 
121  capabilities  were  demonstrated  to  work  effectively,  with  six  of  those  being  additions 
to  what  was  originally  planned  for  ED-1.  (Capability  refers  to  items  listed  in  Appen¬ 
dix  B.)  An  additional  11  capabilities  were  ready  for  ED-1  but  were  not  demonstrated 
because  they  could  not  be  fit  into  the  scenarios.  There  were  two  capabilities  (dropping 
trains  of  bombs  and  close  control  of  aircraft  by  an  E2)  that  were  incorrectly  or  incom¬ 
pletely  implemented  could  not  be  demonstrated  at  all. 

b.  FWA  PCRs.  Although  a  capability  was  performed,  in  some  cases,  there  were  errors  in  the 
exact  details  of  how  the  capabihty  was  performed.  During  ED-1,  24  problem  change 
requests  were  identified.  Three  were  removed  (determined  not  to  be  real  problems),  two 
were  deferred  (determined  to  require  fixes  from  other  groups — OS),  six  were  not  fixed 
(low  priority),  and  12  were  fixed. 

c.  RWA  Capabilities.  By  the  second  day,  all  missions  were  flown  correctly.  A  total  of 
49.5  capabilities  were  demonstrated  to  work  effectively,  with  six  of  those  being  additions 
to  what  was  originally  expected  for  ED-1.  An  additional  five  capabilities  were  ready  for 
ED-1  but  were  not  demonstrated  because  they  could  not  be  fit  into  the  specific  scenarios. 
There  were  5.5  capabilities  that  we  had  planned  on  demonstrating  but  that  were  not  com¬ 
pletely  ready  for  ED-1.  A  further  four  capabilities  that  we  had  planned  on  demonstrating 
were  found  out  through  further  Knowledge  Acquisition  (KA)  to  actually  be  inappropriate 
and,  thus,  were  not  demonstrated  in  ED-1. 

d.  RWA  PCRs.  Although  a  capability  was  performed,  in  some  cases,  there  were  errors  in  the 
exact  details  of  how  the  capability  was  performed.  Based  on  an  analysis  of  our  notes 
from  ED-1,  24  problem  change  requests  were  identified  relating  to  RWA.  Of  this  total. 
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nine  have  been  fixed  or  had  substantial  work  done  on  them,  five  were  deferred,  and  10  are 
either  just  beginning  or  waiting  to  be  worked  on. 

3.  Army  .SF.  All  comments  and  data  were  collected  and  organized  by  vignette.  There  were  three 
vignette  scenarios  played  during  ED-1,  19-20  October  1995. 

2.3.2  Navy  Data  Summary 

ED-1  was  conducted  from  17-20  Ocober  1995.  On  the  first,  third,  and  fourth  day  of  ED-1,  Army 
SF,  CFOR,  Navy  SF,  MCSF,  and  AFSF  participated  from  geographically  dispersed  sites  (NRaD, 

IDA,  WISSARD,  and  JTASC).  On  the  second  day,  only  Navy  SF,  supported  by  Navy  AirSAF  at 
WISSARD,  ran  scenarios.  The  same  version  of  Navy  SF  (version  1.4.0.AC)  was  run  during  all  four 
days  of  ED-1.  Three  front-ends  and  11  back-ends  were  used.  The  entity  count  on  the  first  day  was 
less  than  300  entities,  except  during  the  last  hour  of  the  exercise,  when  there  were  389  entities.  On 
the  second  day,  the  entity  load  was  much  lower  since  only  two  sites  participated.  On  the  third  and 
fourth  day,  there  were  300  to  400  entities  most  of  the  time.  During  peak  traffic  load,  there  was  a 
maximum  of  457  entities.  During  ED-1,  the  CG-59,  DDG-51,  CVN-68,  DD-963,  and  AOE-6  class 
engineering,  operations,  and  weapons  systems  and  sensors  requirements  were  evaluated.  Observa¬ 
tions  were  recorded  to  determine  the  number  of  times  that  a  requirement  was  demonstrated  correctly 
(passed)  and  the  number  of  times  a  requirement  was  demonstrated  incorrectly  (failed).  In  some 
cases,  observation  of  a  specific  requirement  was  not  recorded,  even  though  it  may  have  been  exer¬ 
cised  during  ED-1.  For  maneuvering,  the  DDG-51  passed  twice,  while  the  DD-963  failed  twice.  For 
Voice  Nets  (CCSIL),  there  were  1 1  failed  attempts  with  several  different  hulls.  For  the  Mk  45  5-inch 
gun,  the  CG-59  passed  four  times;  the  DDG-51  passed  10  times  and  failed  once;  and  the  DD-963 
passed  six  times  and  failed  once.  For  the  Mk  34/86  Gun  Fire  Control  System  (GFCS),  the  CG-59 
passed  once;  the  DDG-51  passed  six  times;  and  the  DD-963  passed  three  times.  For  the  Mk  15 
Close-In  Weapon  System  (CIWS),  the  CG-59  passed  twice  and  failed  once;  the  DDG-51  passed 
eight  times;  the  CVN-68  passed  once;  the  DD-963  passed  three  times;  and  the  AOE-6  passed  three 
times  and  failed  once.  For  the  Aegis  Weapon  System  (AWS),  the  CG-59  passed  16  times,  and  the 
DDG-51  passed  five  times.  For  the  Tomahawk  Weapon  Control  System  (TWCS),  the  CG-59  passed 
six  times,  and  the  DDG-51  passed  three  times.  For  the  Harpoon  Weapon  System  (HWS),  the  CG-59 
passed  five  times;  the  DDG-51  passed  nine  times  and  failed  once;  and  the  DD-963  passed  four  times. 
For  the  Mk  57  NATO  Sea  Sparrow  Missile  System  (NSSMS),  the  CVN-68  passed  two  times;  the 
DD-963  passed  five  times  and  failed  once;  and  the  AOE-6  passed  four  times.  For  the  Harpoon  mis¬ 
sile  (launch,  not  flyout),  the  CG-59  passed  four  times,  and  the  DDG-51  passed  six  times.  For  the 
Tomahawk  Missile  (launch,  not  flyout),  the  CG-59  passed  six  times,  and  the  DDG-5 1  passed  three 
times.  For  the  SM2  Missile  (launch,  not  flyout),  the  CG-59  passed  15  times,  and  the  DDG-51  passed 
nine  times.  For  the  SS  Missile  (launch,  not  flyout),  the  DD-963  passed  once,  and  the  AOE-6  passed 
once.  When  problems  were  found,  formal  PCRs  were  generated  and  passed  on  to  configuration 
management.  During  ED-1,  29  PCRs  were  generated;  14  were  Navy  SF  problems,  10  were  OS 
problems,  and  five  were  ModStealth  problems.  Appendix  A  contains  a  summary  of  all  the  Navy  SF 
PCRs.  Complete  copies  with  more  detailed  descriptions  are  available  from  the  Navy  SF  Configura¬ 
tion  Manager. 

2.3.3  Marine  Corps  Data  Summary 

The  test  results  for  MCSF  are  divided  into  four  major  categories.  They  are  individual  combatants 
(IC)  that  included  a  rifle  squad,  a  60-mm  mortar  squad,  a  M240  machine  gun  squad,  and  an  assault 
team  commanded  by  a  platoon  commander.  Secondly,  the  MlAl  Tank  platoon.  Light  Armored 
Reconnaissance  (LAR)  section,  LAR-M  (mortar)  section,  and  LAR-AT  (anti-tank)  sections  made  up 
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the  Armored  element.  Thirdly,  an  Amphibious  Assault  Vehicle  (AAV)  platoon,  LVT-C7  with  chase, 
TOW  CAAT  teams,  TOW  section,  and  LVT-R7,  made  up  the  Mechanized/Anti-mechanized  element. 
Finally,  the  CH-53,  CH-46,  AH-1,  and  AV8B  are  the  Air  elements.  All  of  these  categories  are  tested 
within  the  context  of  the  main  ED-1  Test  Continuum  objective.  The  main  ED-1  Test  Continuum 
objectives  were  to  constitute  United  States  Marine  Corps  (USMC)  military  forces  as  a  Marine  Corps 
Company  with  attachments,  and  as  a  Marine  Corps  Infantry  Platoon,  and  to  conduct  USMC  Move- 
ment-to-Contact  (at  the  company  level)  and  Day  Attack  (at  the  platoon  level).  As  a  result  of  ED-1 
testing,  51  PCRs  were  generated  for  MCSF.  These  PCRs  were  submitted  to  the  MCSF  Configuration 
Management  Manager.  As  of  20  November  1995,  21  of  these  PCRs  were  fixed,  tested,  and  closed; 
10  PCRs  were  fixed  and  awaiting  test;  and  20  PCRs  are  being  fixed  or  deferred  to  ED-2.  Appendix 
A  contains  a  summary  of  the  MCSF  PCRs. 

2.3.4  Air  Force  Data  Summary 

As  stated  in  paragraph  2.1,  all  data  were  collected,  with  the  exception  of  the  data  logger,  through 
personal  observations  of  entity  behaviors  using  the  ModSAF  PVD.  Task  Frames  were  used  to  con¬ 
trol  behaviors  of  the  F-16C,  A-10,  and  FAC  entities  in  the  CAS  role  and  of  the  F-16C  in  the  Air 
Interdiction  (AJ)  role.  The  four  major  areas  of  behavior  for  the  A-10  and  F-16C  evaluated  were 

1 .  Ingress; 

2.  Contact  Point; 

3.  Attack  Phase; 

4.  Egress  along  with  the  communications  with  the  FAC. 

Both  the  A-10  and  F-16C  Ingress  and  Egress  had  problems  with  formations,  but  airspeed,  altitude, 
and  route-following  were  good  when  ED-1  concluded.  Contact  Point  and  FAC  communication  were 
good  but  only  Time-on-Station  was  tested  to  end  the  CAS  task.  BINGO  fuel  and  weapons  expendi¬ 
ture  were  not  tested  for  ending  the  CAS  task.  For  CAS,  there  were  several  major  problems  in  the 
Attack  Phase,  mainly  with  target  acquisition  and  target  priority.  Target  damage  was  not  as  expected 
during  the  Attack  Phase. 

2.3.5  SE  Data  Summary 

The  first  scenario’s  purpose  was  to  showcase  the  many  features  introduced  by  SE  to  STOW.  The 
first  scenario  was  divided  into  four  vignettes,  each  vignette  with  a  number  of  events.  Vignette  1  had 
12  events,  vignette  2  had  four  events,  vignette  3  had  three  events,  and  vignette  4  had  four  events. 
ModStealth  was  used  to  correctly  visualize  these  events.  ModStealth  is  a  RITN  interface  between 
ModSAF  and  a  Computer  Image  Generator  (CIG).  For  ED-1,  the  CIG  used  throughout  was  Vista- 
Works.  Other  CIGs  are  expected  to  be  connected  to  ModStealth  to  compare  and  analyze  the 
strengths  and  weakness  of  each  platform.  The  matrix  in  section  3.2. 1.2  lists  the  individual  events 
and  their  results  in  each  vignette  for  the  first  scenario.  The  second  scenario,  called  the  Samarian 
Trench,  was  to  integrate  many  of  the  features  that  SE  introduced  to  STOW  and  to  demonstrate  the  SE 
work  in  a  distributed  environment.  This  scenario  contained  1 1  events  and  was  modeled  after  a  pre¬ 
vious  live  exercise  at  the  National  Training  Center  (NTC).  The  results  of  this  scenario  was  highly 
successful,  though  there  was  one  notable  exception  that  was  corrected.  During  the  scenario,  after  the 
Armored  Vehicle  Launched  Bridges  (AVLB)  bridges  were  successfully  laid  across  the  anti-tank 
ditch,  there  were  a  number  of  vehicles  that  tracked  directly  toward  the  anti-tank  ditch  and  fell  into 
the  ditch,  rather  than  correctly  laying  a  route  to  the  other  side  of  the  ditch  via  the  AVLB  bridges. 
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Several  other  vehicles  did  make  the  correct  route  across  the  bridges,  and  successfully  crossed  the 
anti-tank  ditch.  A  patch  for  ModSAF  to  correct  this  routing  problem  was  available  the  morning  of 
the  exercise,  but  a  decision  was  made  at  TEC  not  to  make  the  change.  This  last-minute  patch  was 
not  tested  over  the  net,  and  it  was  not  known  whether  there  would  be  any  other  ill  effects  on  the  pro¬ 
gram  by  making  this  change.  This  patch  has  since  been  tested,  and  the  scenario  now  works  properly. 
Overall,  the  first  day  of  ED-1  was  considered  highly  successful  by  demonstrating  the  work 
introduced  by  SE  to  the  STOW  community,  and  interfacing  with  all  the  outlying  sites  participating  in 
the  demonstration  using  the  new  Real-Time  Information  Transfer  and  Networking  (RITN)  code. 
Though  the  RITN  code  was  not  part  of  the  SE  work,  there  was  considerable  cooperation  between  the 
two  programs  to  make  the  code  work  for  this  part  of  the  demonstration  of  ED-1. 
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3.  ANALYSIS 


3.1  METHODS 

The  methods  used  for  analysis  varied  for  the  different  technology  areas.  The  following  paragraphs 
describe  each  technological  area’s  methods  of  analysis. 

3.1.1  Army  Analysis  Methods 

1 .  CFOR.  The  CFOR  Analysis  methods  called  for  a  Subject  Matter  Expert  (SME),  Scott  Carey,  a 
retired  career  Army  Armor  officer  from  Logicon  RDA,  to  witness  the  CFOR  behavior  via  the 
ModSAF  GUI  and  ModStealth,  and  record  results  subjectively.  The  CFOR  monitor  captured 
and  displayed  CCSIL  messages.  Additionally,  the  ACUSOFT  data  logger  recorded  results  for 
later  playback,  as  required. 

2.  IFOR.  Analysis  for  FWA  was  performed  in  two  phases.  The  first  phase  was  on-site  during 
ED-1  by  technical  personnel  observing  the  behavior  of  the  agents  and  checking  for  correct 
execution.  The  second  phase  was  an  analysis  by  Mark  Checchio  (former  USN  pilot)  of  BMH 
based  on  communication  logs  and  repeats  of  the  scenarios.  Analysis  for  RWA  was  performed 
primarily  on-site  during  ED-1  by  Information  Sciences  Institute  (ISI)  technical  personnel  and 
Captain  Don  Lassiter  of  Fort  Rucker  observing  the  behavior  of  the  agents.  However,  some 
post-analysis  was  done  based  on  the  notes  taken  during  ED-1  (such  as  the  extraction  of  a  list  of 
PCRs). 

3.  Army  Synthetic  Forces.  A  two-step  data  reduction  and  consolidation  process  was  used  from 
the  data  that  were  collected  from  the  SMEs’  assessment  templates.  First,  conunents  were  col¬ 
lected  and  organized  by  vignette.  Second,  a  roll-up  of  the  comment  database  was  organized 
into  nine  categories  that  represent  the  Primary  Tactical  Assessment  Results.  These  categories 
included  the  following: 

•  Planning  and  coordination,  mission  preparation; 

•  Synthetic  environment;  interoperability,  and  mission  objectives; 

•  Order  of  battle; 

•  Red  and  Blue  Forces; 

•  Coordination  with  interoperating  forces; 

•  CFOR; 

•  IFOR  and  ModSAF  comparison; 

•  Service  contributions  and  mission  completion; 

•  Data  collection  and  reporting. 

These  broad  areas  of  concern  also  had  several  subcategories  for  additional  detail.  Note  that  some  of 
the  perceived  weaknesses  were  there  by  design — known  hardware  limitations,  stopping  points  in  the 
scenario,  lack  of  specific  C^  structure  above  the  participating  units,  etc. 

3.1 .2  Navy  Analysis  Methods 

The  Navy  analysis  methods  were  divided  into  Navy  Air  (WISSARD)  and  Navy  Surface. 
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1.  Navy  Air.  WISSARD  logged  all  PDU  traffic  received  at  WISSARD,  utilizing  the  LORAL- 
developed  ModSAF  data  logger.  The  primary  purpose  was  for  playback  and  reconstruction. 
Although  a  rudimentary  look  could  be  performed  to  determine  the  information  contained 
within  each  PDU,  a  worthwhile  analysis  of  this  data  would  require  additional  hardware  not 
presently  available  to  WISSARD.  The  primaiy  analysis  method  was  through  retired  military 
SMEs  viewing  the  entire  series  of  events  on  SGI  Indy  R4000  series  computers.  The  total  anal¬ 
ysis  effort  was  a  team  effort  in  which  the  member  with  the  most  experience  and  expertise  for 
the  event  observed  the  behaviors  and  performance,  then  reported  the  results  for  recording.  All 
performance  and  behaviors  cannot  be  fairly  evaluated  until  valid  models  representing  aircraft 
systems  and  performance  are  developed  and  implemented.  Although  behaviors  and  perfor¬ 
mance  are  all  considered  inadequate  for  valid  representation,  they  are  a  quantum  improvement 
over  present  systems.  Table  4  lists  the  SME  qualifications.  The  following  analyses  were  con¬ 
ducted  by  WISSARD  personnel: 

a.  Navy  AirSAF 

(1)  Performance  of  Carrier  Battle  Group  air  operations  in  support  of  an  air  tasking  order 
disseminated  by  a  JFACC.  Executed  continuous  operations  involving  all  warfare 
areas  presently  represented  in  AirSAF.  Basic  representation  of  air  capabilities  was 
adequate  to  support  large  campaign-level  exercises.  Individual  performance  of  enti¬ 
ties  to  execute  certain  aspects  of  their  missions  range  from  adequate  to  unsatisfactory 
or  nonexistent,  dependent  on  which  behavior  was  evaluated. 

(2)  IFOR  FWA  performance  in  support  of  fulfilling  air  tasking  order  requirements  with 
realistic  behaviors  in  AAW,  STW,  CAS,  AEW,  FAC,  Suppression  of  Enemy  Air 
Defense  (SEAD),  and  Air-to-Air  Refueling  (AAR).  Behaviors  exhibited  by  IFOR 
agents  flying  AirSAF  vehicles  simulated  real-world  performance  to  a  degree  of  fidel¬ 
ity  previously  unavailable  in  modeling  and  simulation.  Of  key  importance  was  the 
incorporation  of  the  element  of  Command  and  Control  from  one  SF  entity  to  another 
in  numerous  mission  areas  utilizing  plain  English  voice  communications.  IFOR 
agents  demonstrated  as  close  to  human  performance  as  is  presently  available  any¬ 
where  in  simulation.  The  greatest  deficiency  evident  was  the  limitation  placed  on  the 
agents’  performance  due  to  inadequacy  of  the  models  making  up  the  physical 
vehicles  utilized  by  each  agent. 


Table  4.  WISSARD  SMEs. 


Service/Rank 

Experience 

(years) 

Area  of  Expertise 

Navy  Commander 

20 

Fighter/Command/Strike 

Army  Colonel 

28 

Helicopter/Command 

Marine  Lt.  Colonel 

26 

Infantry/Reconnaissance 

Marine  Lt.  Colonel 

23 

Artillery/Special  Ops 

Navy  Lieutenant 

22 

Aegis  Ninja/FAAWC 

Navy  LCDR 

6 

Deep  Strike/CAS 

Navy  LCDR 

16 

Fighter 

Marine  CAPT 

12 

1  nfantry/Reconnaissance 

16 


b.  Fixed  Wing  Aircraft  (FWA) 

(1)  Tactical  performance  and  behavior  of  AirSAF  vehicles  in  performing  air  missions 

. .  associated  with  all  warfare  areas  executed  by  a  Carrier  Air  Wing  in  fulfilling  require¬ 
ments  of  an  air  tasking  order.  With  the  goal  of  simulating  real-world  performance 
and  behaviors  using  AirSAF,  the  present  system  is  unsatisfactory.  This  is  due  primar¬ 
ily  to  the  inadequacies  of  the  models  used  to  define  systems  or  physical  attributes 
needed  to  drive  behaviors.  Until  the  proper  models  are  developed,  a  representation 
of  behaviors  and  a  fair  evaluation  of  the  SAF  systems  capabilities  cannot  be 
achieved.  The  following  list  is  but  a  fraction  of  the  known  models  that  are  either 
inadequate  or  nonexistent; 

(a)  Aerodynamics; 

(b)  Flight  Performance; 

(c)  Thrust; 

(d)  All  active  sensors  (radar,  lasers,  etc.); 

(e)  All  passive  sensors  (IRST,  NCTR,  RHAW,  \^sual,  etc.); 

(f)  Countermeasures  (Electronic,  Infrared,  Mechanical,  etc.); 

(g)  Fuel; 

(h)  Weapon  Launch  Acceptability  Regions; 

(i)  Communications. 

(2)  Tactical  aircraft  performance  in  a  defensive  role  when  countering  an  attack.  Unsatis¬ 
factory  in  all  areas.  AirSAF  vehicles  are  incapable  of  performing  any  type  of  defen¬ 
sive  maneuver  to  defeat  an  attack  launched  against  them.  This  major  deficiency  can 
be  attributed  primarily  to  the  following  three  areas: 

(a)  Lack  of  sensors  to  indicate  an  entity  is  under  attack; 

(b)  Nonavailability  of  countermeasures; 

(c)  Nonexistent  defensive  behaviors  required  to  defeat  incoming  attacks. 

(3)  Ordnance  probability  of  hit  and  probability  of  kill  for  targets  under  attack.  An  appar¬ 
ent  weakness  exists  in  the  damage  model  for  all  types  of  ordnance.  The  number  of 
hits  required  to  kill  an  entity  or  the  number  of  hits  that  could  be  absorbed  by  an  entity 
seemed  unrealistically  high  based  on  real-world  historical  data.  As  an  example,  in 
the  air-to-ground  arena,  an  engagement  between  a  Blue  helicopter  and  Red  tank,  in 
which  10  hits  appeared  to  be  scored  by  Mavericks  from  the  helicopter,  no  kill 
occurred.  In  the  air-to-air  arena,  numerous  tactically  valid  shots  were  taken  with  no 
defensive  maneuvers  taken  by  the  targets,  with  no  valid  hits  or  kills  scored.  As  a 
general  observation,  it  appeared  that  for  the  number  of  weapons  launched/expended 
in  a  tactically  valid  envelope,  the  probability  of  achieving  a  hit  and/or  kill  was  lower 
than  what  would  be  expected  based  on  historical  data.  Further  detailed  analysis  is 
required  to  determine  the  cause  of  this  problem  due  to  WISSARD’s  inability  to  per¬ 
form  an  in-depth  analysis  of  PDUs.  These  outcomes  could  be  due  to  a  variety  of 
problems  such  as  network  loading,  inadequate  targeting  systems,  or  inaccurate  dam¬ 
age  assessment/probability  models.  Due  to  its  large  effect  on  much  of  the  battle 
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space  and  final  outcomes,  finding  a  solution  to  this  problem  should  be  given  high 
priority. 

c.  Rotary  W^ing  Aircraft  (RWA) 

(1)  Tactical  performance  and  behavior  of  RWA  vehicles  in  performing  air  missions 
associated  with  fulfilling  requirements  from  higher  authority.  With  the  goal  of  simu¬ 
lating  real-world  performance  and  behaviors  using  AirSAF,  the  present  system  is 
unsatisfactoiy.  Excessive  manual  intervention  is  presently  required  to  achieve  what 
appears  to  be  adequate  performance.  This  is  due  primarily  to  the  inadequacies  of  the 
models  used  to  define  systems,  or  the  physical  attributes  needed  to  drive  behaviors. 
Until  the  proper  models  are  developed,  a  representation  of  behaviors  and  a  fair  evalu¬ 
ation  of  the  SAP  systems  capabilities  cannot  be  achieved.  The  following  list  is  but  a 
fi-action  of  the  known  models  that  are  either  inadequate  or  nonexistent: 

(a)  Aerodynamics; 

(b)  Flight  Performance; 

(c)  Thrust; 

(d)  All  active  sensors; 

(e)  All  passive  sensors; 

(f)  Countermeasures; 

(g)  Fuel; 

(h)  Weapon  Launch  Acceptability  Regions; 

(i)  Communications. 

(2)  RWA  performance  in  a  low-altitude  environment  where  contact  with  environmental 
and  large  groups  of  differing  entities  occurs.  RWA  are  in  much  closer  and  in  more 
frequent  contact  with  various  entities  in  the  synthetic  environment  (friendly  and 
OPFOR  platforms,  individual  combatants,  and  environmental  entities)  than  FWA. 
These  large  numbers  of  multiple  types  of  entities  that  RWA  are  required  to  process 
result  in  excessive  drops  in  performance  capability  that  are  unsatisfactory.  RWA 
experienced  excessive  amounts  of  overloaded  conditions  (i.e.,  unexpected  deviations 
from  planned  routes,  flying  into  the  ground,  erratic  performance)  during  high  net¬ 
work  traffic  periods.  Behaviors  improved  dramatically  when  operating  on  a  pocket 
system  when  network  traffic  load  was  much  lighter.  This  also  held  true  for  IFOR 
RWA  behaviors. 

d.  Ordnance  Server 

(1)  Compare  the  performance  of  ModSAF  missiles  flyouts  vs.  those  provided  through 
use  of  the  OS.  Although  problems  were  encountered  with  the  OS,  the  improvement 
in  missile  flyout  performance  and  capability  was  impressive.  The  ability  of  aircraft 
to  employ  missiles  in  many  more  regions  of  the  actual  envelope  was  a  marked 
improvement  over  the  highly  restrictive  ModSAF  missiles.  In  addition,  the  use  of 
validated  and  realistic  flyouts  produced  engagements  that  were  more  indicative  of 
real-world  outcomes.  Current  limitations  and  required  enhancements  for  the  OS  are 
as  follows: 
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(a)  OS  success  can  be  dependent  on  hardware  utilized  to  implement  it.  Utilizing  an 
R3000-based  machine  to  simulate  missile  flyouts  and  high  network/system  load¬ 
ing  caused  numerous  irregularities  and  system  crashes.  This  often  resulted  in  no 
missile  flyouts  during  engagements. 

(b)  Using  an  SGI  R4(X)0  series  (preferably  R4400)  seemed  to  work  adequately  with 
some  minor  exceptions  throughout  ED-1  when  tasked  to  serve  a  maximum  of 
two  instances  in  the  air-to-air  arena.  The  two  instances  appeared  to  be  a  maxi¬ 
mum  for  R4400  machines.  Placement  of  a  third  instance  on  the  machine  always 
precipitated  a  crash  that  required  rebooting  to  reinitiate  the  OS  function.  Further 
investigation  of  this  phenomena  is  required. 

(c)  The  OS  is  unable  to  support  missile  flyouts  if  any  maneuver  is  performed  by  the 
launching  aircraft.  Loss  of  the  missiles  occurs  100%  of  the  time  following  even 
mild  maneuvers.  The  message  received  is  “radar  illumination  lost,”  which 
should  not  be  the  case,  based  on  SME  observation.  Further  investigation  of  this 
phenomenon  is  required. 

(2)  How  well  does  the  OS  support  IFOR  in  the  employment  of  weapons  during  mission 
execution.  IFOR  agents  enjoyed  a  much-improved  capability  to  employ  valid  weap¬ 
ons  during  ED-1  using  the  OS.  However,  their  behavior  in  performing  valid  tactics 
during  air-to-air  engagements  created  problems  for  the  OS  in  supporting  flyouts  for 
reasons  that  were  not  valid  (i.e.,  radar  illumination  lost)  based  on  observations. 

(3)  OS  ordnance  libraries  possess  the  required  ordnance  models  to  support  present  and 
future  exercises.  The  existing  OS  library  is  severely  lacking  in  the  required  ordnance 
models  needed  to  support  SF  and  their  use  during  large-scale  exercises,  especially  in 
the  air-to-air  arena,  where  the  OS  capabilities  greatly  improve  existing  SF  weapons. 
As  an  example,  the  OS  is  unable  to  support  the  Advanced  Medium  Range  Air-to-Air 
Missile  (AMRAAM)  missiles  even  though  it  is  presently  in  wide  use  by  U.S.  air 
defenses.  In  addition,  existing  capabilities  that  exist  in  weapons  are  not  available  in 
some  cases  with  OS  missiles.  One  glaring  example  is  the  launch-and-leave  capability 
of  the  Phoenix  missile. 

(4)  Examine  the  OS  capability  to  support  smart  air-to-ground  weapons  flyouts  in  large 
SF  exercises  with  realistic  performance  and  results.  The  ordnance  server’s  library  of 
air-to-ground  smart  weapons  is  almost  nonexistent.  A  Maverick  with  very  limited 
capability  exists  that  is  much  better  than  the  ModSAF  Maverick,  but  it  is  still  much 
less  capable  than  the  real  weapon,  which  may  actually  be  more  a  function  of  AirSAF 
deficiencies.  BMH  Associates  has  supplied  a  list  of  desired/required  weapons  to 
Patuxent  River  for  incorporation  into  the  OS  for  the  Marine  Corps  and  the  Navy. 

2.  Navy  Surface.  For  Navy  Surface,  analysis  was  performed  by  a  Senior  Test  Engineer  and  a 
Senior  Systems  Analyst  with  Naval  Surface  Warfare  experience.  The  ED-1  results,  which  are 
recorded  observations  of  entity  appearance,  characteristics,  and  operational  capabilities  as 
viewed  on  the  ModSAF  PVD  or  ModStealth  display,  were  compared  with  the  expected  entity 
appearance,  characteristics,  and  operational  capabilities  in  accordance  with  Navy  SF  software 
requirements.  Table  5  lists  the  25  Navy  SF  ED-1  items  that  were  analyzed.  All  NSF  ED-1 
recorded  results  were  categorized  by  analysis  item  and  by  specific  hull.  The  results  were  then 
compared  with  the  software  requirements  from  the  Navy  SF  Project  Management  Notebook 
for  that  specific  hull.  After  determining  the  pass  or  fail  status  of  the  tested  requirements,  each 
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Table  5.  Navy  SF  ED-1  analysis  items. 


Capability 

Result 

Engineering  -  Basic  Hull 

Satisfactory 

Engineering  -  Powerplant 

Satisfactory 

Engineering  -  Fuel  consumption 

Not  Obsen/ed 

Operations  -  Maneuvering 

Satisfactory 

Operations  -  GPS 

Satisfactory 

Operations  -  Voice  Nets 

Unsatisfactory 

Weapons  Systems  -  Mk  45  5-inch  GUN 

Satisfactory 

Weapons  Systems  -  Mk  34  /86  GFCS 

Satisfactory 

Weapons  Systems  -  Mk  15  CIWS 

Unsatisfactory 

Weapons  Systems  -  Mk  7/8  AWS 

Satisfactory 

Weapons  Systems 

Satisfactory 

Weapons  Systems  -  HWS 

Satisfactory 

Weapons  Systems  -  Mk  57  NSSMS 

Satisfactory 

Weapons  Systems  -  Harpoon  Missile 

Satisfactory 

Weapons  Systems  -  Tomahawk  Missile 

Satisfactory 

Weapons  Systems  -  SM2  Missile 

Satisfactory 

Weapons  Systems  -  Sea  Sparrow  Missile 

Satisfactory 

Weapons  Systems 

Satisfactory 

Weapons  Systems  -  AN/SPS-49 

Satisfactory 

Weapons  Systems  -  AN/SPS-55 

Satisfactory 

Weapons  Systems  -  AN/SPS-67 

Satisfactory 

Weapons  Systems  -  AN/SPS-40 

Satisfactory 

Weapons  Systems  -  AN/SPS-48E 

Satisfactory 

Weapons  Systems  -  AN/SPS-64 

Satisfactory 

Weapons  Systems  -  SH-60  LAMPS  Mk  III 

Unsatisfactory 

of  the  25  items  were  evaluated,  with  consideration  of  UVT  and  IT  results,  and  were  given  an 
overall  rating  of  satisfactory  or  unsatisfactory. 

3.1.3  Marine  Corps  Analysis  Methods 

Over  93  major  testable  items  including  creation  of  simulated  entities,  as  well  as  their  behaviors, 
were  tested.  Please  refer  to  the  MCSF  Test  Plan  for  the  description  of  these  items.  The  integration 
tests  were  repeated  nine  times  to  identify  catastrophic  software  failures  as  well  as  future  enhance¬ 
ments.  The  total  number  of  the  execution  of  testable  items  was  over  837.  During  the  9  days  of  the 
Subsystem  Integration  Test  (SSIT)  #4/ED-l  test  continuum,  51  software  problems  were  identified 
(see  Appendix  A).  For  ED-1,  MCSF  exit  criteria  verified  that  the  forces  can  be  constituted  as  a 
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coherent  grouping  and  be  commanded  by  a  human  company  commander  and  operate  as  if  they  were 
a  company-level  force.  The  measure  of  success  is  the  reasonableness  of  overall  company-level 
movement  to  contact  behavior.  Ratings  of  coordinated  movement  were  performed  by  in-house 
SMEs  (qualifications  contained  in  paragraph  3.1)  for  company-level  movement  to  contact.  In  addi¬ 
tion,  MCSF  exit  criteria  also  verified  that  the  platoon  could  be  commanded  to  operate  as  a  militarily 
significant  force.  The  platoon  test  issues  center  on  the  three  phases  of  a  platoon  day  attack:  prepara¬ 
tion,  attack,  and  exploitation.  The  measure  of  success  is  the  reasonableness  of  overall  platoon  attack 
behavior.  Ratings  were  performed  by  in-house  SMEs  for  platoon-level  attack.  The  ratings  were 
categorized  as  follows: 

1 .  Fleet  end-user  acceptance; 

2.  STOW  97  acceptance; 

3.  ED-1  acceptance; 

4.  Marginal  ED- 1  acceptance; 

5.  Not  acceptable. 

For  each  of  the  testable  items,  in-house  SMEs  provided  the  ratings  that  were  then  normalized  to 
derive  overall  ratings  for  ED-1  capabilities.  Entity-level  test  objectives  supported  overall  MCSF 
mission-based  integrated  test  objectives  for  Light  Armored  Company  and  Rifle  Platoons: 

1.  MCSF  entity  control  using  voice  conunands  (CommandTalk); 

2.  MCSF  Testing  with  IDA  over  DSI; 

3.  Major  Test  Vignettes  of  USMC  Mission; 

4.  Testing  of  physical  attributes; 

5.  Testing  of  entity  behavior  to  support  USMC  mission; 

6.  Marine  Corps  Ground  Vehicles; 

7.  Total  Test  Criteria  =  93 ; 

8 .  SSIT  #4  Total  #  of  Failed  Test  Criteria  =  51*; 

9.  ED-1  Total  #  of  Failed  Test  Criteria  =  20; 

10.  ED-1:  78%  Development  Success. 

*Includes  duplication  of  PCRs  and  operator  errors. 

3.1 .4  Air  Force  Analysis  Methods 

The  Electronics  System  Command  (ESC),  utilizing  an  in-house  retired  military  person  with  opera¬ 
tional  experience  as  the  SME,  worked  with  LADS  and  identified  desired  behaviors  for  a  FAC,  A-10, 
and  F-16C  in  the  CAS  role  and  the  F-16C  in  the  AI  role.  USAF/XOM  and  Armstrong  Laboratory 
also  provided  input.  Four  major  areas  of  evaluation  for  the  A-10  and  F-16C  were  identified  as  fol¬ 
lows; 

1.  Ingress; 

2.  Contact  Point; 
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3.  Attack  Phase; 

4.  Egress,  along  with  FAC  communications. 

Each  area  contained  a  specific  evaluation  of  one  or  more  of  the  following:  platform  performance, 
sensor  performance,  weapon  performance,  and  pilot  behaviors.  Platform  performance  required  that  a 
specific  parameter  be  met,  such  as  an  airspeed  of  480  kn  ( ±  40  kn)  on  a  low-level  route.  Sensor  per¬ 
formance  required  that  it  reasonably  simulated  the  real  sensor  and  initiated  a  pilot  behavior,  such  as 
visually  acquiring  and  identifying  a  target  leading  to  the  pilot  attacking  the  target.  Weapons  perfor¬ 
mance  required  that  the  employment,  which  is  tied  to  pilot  behaviors,  weapon  accuracy,  and  damage 
effect  be  realistic  to  the  real  weapon.  An  example  would  be  that  a  AGM-65  Maverick  would  be 
employed  in  a  standoff  mode,  and  after  firing  the  plane,  would  turn  away  fi'om  the  target  vs.  overfly¬ 
ing  the  target.  Also,  the  accuracy  and  damage  to  the  target  would  be  reasonably  similar  to  the  real 
AGM-65.  Pilot  behavior  required  that  a  reasonable  but  simple  behavior  be  initiated  based  on  the  sit¬ 
uation  and  sensor  input  at  the  time,  such  as  communicating  with  the  FAC  and  acting  on  the  informa¬ 
tion  passed  by  the  FAC.  There  were  a  total  of  five  vignettes  consisting  of  three  CAS  and  two  AI. 
CAS  consisted  of  both  A- 10  and  F-16C  missions  with  a  FAC  and  attacked  OPFOR  ground  vehicles 
(mostly  tanks).  The  AI  vignettes  consisted  of  F-16C  only,  but  attacked  two  types  of  targets.  One 
target  set  was  dynamic  bridges  provided  by  Synthetic  Environment,  and  the  other  set  was  OPFOR 
tanks.  Nine  test  periods  were  conducted  of  the  five  ED-1  vignettes.  During  and  after  each  testing 
period,  ESC  and  LADS  personnel  reviewed  their  observations  and  identified  discrepancies  between 
the  desired  and  actual  entity  behaviors.  On  several  occasions,  USAF/XOM  provided  personnel,  and 
their  observation  were  also  recorded.  LADS  then  reviewed  the  discrepancies  at  their  Cambridge 
facility  and  made  changes  to  AFSF  that  could  be  implemented  before  and  reevaluated  during  the 
next  test  period. 

3.2  RESULTS  SUMMARY,  DISCUSSION,  AND  CONCLUSIONS 

ED-1  demonstrated  the  current  maturity  of  the  technologies  resulting  in  integrated  phenomenol¬ 
ogy,  integrated  dynamic  terrain,  and  an  improved  CGF  TDB  within  ModSAF.  The  SF  capabilities 
successfully  accomplished  all  of  their  major  goals  with  some  anomalies  that  need  to  be  developed 
further.  The  SE  effort  was  a  major  success,  with  the  developers  exceeding  the  expectations  of  the 
System  Engineering  &  Integration  (SE&I)  Plan. 

3.2.1  Individual  Technologies 

Synthetic  Forces  and  Synthetic  Environment  results  and  conclusions  are  discussed  in  the  following 
paragraphs. 

3.2.1 .1  Synthetic  Forces.  The  following  paragraphs  describe  the  SF  for  each  of  the  technology 
areas. 

1 .  Army.  The  Army  SF  (ASF)  are  reported  as  CFOR,  IFOR,  and  STRICOM’s  observations  for 
ASF  Red  and  Blue. 

a.  CFOR.  It  is  not  the  intent  of  the  CFOR  program  to  develop  SF  platforms,  but  behaviors 
of  commanders  who  ride  in  SF  platforms.  In  the  Army  Armor/Mechanized  company,  the 
commander’s  vehicle  and  platoons  are  modeled  directly  in  Army  SF  (ModSAF).  Anoma¬ 
lies  in  Army  SF  were  noted,  and  forwarded  to  STRICOM  for  action. 

b.  IFOR.  During  the  STOW  Engineering  Demonstration  #1  (ED-1)  in  October  1995,  the 
goal  of  the  Soar/IFOR  demonstration  was  to  demonstrate  behaviors  (see  section  4.2.2), 
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not  individual  technologies  such  as  airframes,  weapons,  or  sensors.  However,  in  order  to 
demonstrate  behaviors,  the  airframes,  weapons,  and  sensors  provided  in  ModSAF  (some 
had  to  be  enhanced)  were  relied  upon.  An  extensive  evaluation  or  testing  of  these 
technologies  was  not  conducted;  however,  test  personnel  have  extensive  experience  with 
them.  Details  of  the  evaluation  of  ModSAF  support  for  FWA/RWA  flight  dynamics, 
weapons,  and  sensors  are  available  in  a  document  entitled  Required  Extensions  to  Mod¬ 
SAF  (8  November  1995). 

(1)  FWA  Summary.  FWA  demonstrated  the  following  aircraft:  F-14,  F/A-18,  A-10, 
KC-10,  and  E-2C.  Table  6  summarizes  the  FWA  platform  and  capabilities. 

(2)  RWA  Summary.  RWA  demonstrated  groups  of  Apache  AH-64  attack  helicopters. 

The  platforms  were  configured  to  use  only  a  subset  of  “real”  AH-64  capabili¬ 
ties — they  could  fly,  use  a  single  “visual”  sensor,  aim  lasers,  and  fire  Hellfire  mis¬ 
siles.  These  capabilities  were  not  locally  developed,  although  some  of  them  (such  as 
the  Hellfire)  had  to  be  significantly  adapted  by  local  personnel  for  use  by  IFOR 
rather  than  task-based  entities.  Table  6  includes  the  RWA  platform  and  capabilities. 

c.  Army  (Red  and  Blue).  These  are  provided  as  Strengths  and  Weaknesses,  as  shown  below. 

(1)  Strengths  included:  In  one  vignette.  Red  and  Blue  Force  exchange  was  one  for  one, 
showing  a  relatively  level  playing  field.  In  most  vignettes.  Blue  overwhelmed  Red; 
CAS  played  a  significant  role  “Look  ahead”  targeting  was  key.  Once  operators  had  a 
brief  training  opportunity,  they  performed  engineering  support  functions  satisfacto¬ 
rily.  Fidelity  of  representation  of  Red  entities  was  good. 

(2)  Weaknesses  included:  Some  Blue  attrition  was  caused  by  the  operator  not  following 
doctrine,  especially  in  minefields.  Red  should  have  wiped  out  Blue  during  breach¬ 
ing;  operators  took  some  liberties.  (Operators  required  additional  training.) 

2.  Navy.  The  Navy  has  results  from  IFOR,  Navy  Surface,  and  Navy  Air.  These  are  discussed 
below. 

a.  IFOR  focused  on  integrated  FWA  missions  that  required  coordination  among  a  variety  of 
different  airframes.  Although  little  attention  was  focused  on  the  capabilities  of  individual 
entities,  it  was  still  clear  that  there  remains  many  (known)  problems  with  the  ModSAF 
models  of  the  airframe  dynamics,  weapons  systems,  and  radar.  IFOR  (WISSARD)  FWA 
performed  a  number  of  mission  areas  with  the  highest  degree  of  fidelity  presently  avail¬ 
able  in  mission  simulation  via  computer  generated  forces.  Of  key  importance  was  the 
IFOR  ability  to  incorporate  the  element  of  command  and  control  from  another  synthetic 
force  entity  in  performing  the  Air  Warfare  and  CAS  missions.  IFOR  demonstrated  as 
close  to  human  performance  in  the  CAS  and  AAW  as  is  presently  available  in  simulation. 
The  following  IFOR  mission  areas  were  demonstrated  during  ED-1: 

(1)  Air-to-Air  Warfare  (AAW); 

(2)  Strike  Warfare  (STW); 

(3)  Close  Air  Support  (CAS); 

(4)  Airborne  Early  Warning  (AEW); 

(5)  Forward  Air  Control  of  CAS  assets; 

(6)  Suppression  of  Enemy  Air  Defense  (SEAD). 
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Table  6.  Army  IFOR  ED-1  analysis  items. 


Capability 

Result 

FWA  (F-14,  F/A-18) 

Operations  -  Flight  Dynamics 

Unsatisfactory 

Sensor  -  Radar,  RWR 

Unsatisfactory 

Sensor  -  Vision 

Satisfactory 

Weapons  Systems 

Unsatisfactory 

Weapons  Systems  -  PGM,  Bombs 

Unsatisfactory 

Communication  (via  radio) 

Satisfactory 

RWA 

Operations  -  Flight  Dynamics 

Unsatisfactory 

Sensor  -  Vision 

Unsatisfactory 

Weapons  Systems  -  Laser/Hellfire 

Unsatisfactory 

Communication  (via  radio) 

Satisfactory 

b.  Navy  Surface.  Table  5  provides  a  summary  of  the  results.  At  the  STOW  Engineering 
Demonstration  #1  (ED-1)  in  October  1995,  Navy  SF  demonstrated  the  major  platform 
systems  performance  (not  behaviors)  for  a  CVBG  composed  of  an  Aegis  Cruiser,  a 
Guided  Missile  Destroyer,  a  Destroyer,  an  Aircraft  Carrier,  and  a  Logistics  Ship.  The 
major  platform  systems  included  basic  operations  of  sensor  and  weapon  systems,  basic 
maneuvering  operations,  and  damage  modeling  for  each  ship  platform.  The  weapons  sys¬ 
tems  included  a  DIS-capable  OS,  being  provided  by  Naval  Aviation  Warfare  Center-Air¬ 
craft  Division  (NAWC-AD),  for  high  fidelity  flyout  of  the  missiles  launched  by  NSF.  In 
conjunction  with  the  CVBG,  there  was  an  Amphibious  Task  Force  (ATF)  composed  of 
amphibious  assault  ships  (LHD,  LSD,  and  LPD)  and  landing  craft  (LCAC  and  LCU);  a 

.  Mine  Countermeasures  Group  (MCG)  composed  of  mine  hunting  and  sweeping  platforms 
and  entities  (mine  countermeasures  (MCM),  minehunder,  coastal  (MHC),  floating  mine, 
sweep  gear);  an  Opposing  Forces  Surface  Action  Group  (OPFOR  SAG);  and  Navy  Air 
assets  flown  by  the  Navy  Air  Synthetic  Forces  (AirSAF)  developers.  The  ATF,  MCG,  and 
OPFOR  SAG  did  not  yet  contain  their  own  inherent  systems,  but  were  represented  by  the 
major  systems  already  developed  for  the  CVBG.  There  was  an  attempt  to  demonstrate  the 
communications  between  an  SH-60  on  an  OTH  surface-to-surface  engagement  mission, 
flown  by  Air  SF,  and  an  NSF  Aegis  Cmiser.  These  actions  were  to  be  done  automatically 
without  operator  intervention  using  the  CFOR  CCSIL,  which  packages  its  protocols  into 
the  DIS  Signal  PDU.  This  Navy  CCSIL  prototype  is  the  beginning  of  the  behavioral  rep¬ 
resentation  to  be  provided  by  CFOR  efforts  for  the  Navy. 

c.  Navy  Air.  Performed  CVBG  air  operations  in  support  of  an  air  tasking  order.  Executed 
continuous  operations  involving  all  warfare  areas  with  adequate  levels  of  performance 
capable  of  supporting  large  campaign-level  exercises.  Present  SF  capabilities,  although 
very  basic  and  in  some  cases,  marginal,  provided  a  several  orders  of  magnitude  increase 
in  validity  of  air  interactions  compared  to  present  simulation  systems. 

3.  Marine  Corps.  All  4  days  of  ED-1  were  run  as  continuous  scenarios.  The  MCSF  integration 
tests  were  conducted  using  three  vignettes  in  a  procedural  manner.  Each  procedure  (see 
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Appendix  D)  consisted  of  setup,  which  included  entity  creation  and  execution  of  the  test  item 
(which  included  movement,  engagement,  reaction  drill,  and  consolidation  of  MCSF  entities). 
For  each  procedure,  all  observations  were  recorded  throughout  the  exercise  of  the  three 
vignettes.  An  analysis  was  performed  from  these  observations.  As  a  part  of  analysis,  the  defi¬ 
ciencies  were  identified  and  reported  as  a  Problem/Enhancement  Change  Request.  The  results 
of  analysis  were  rated  as  follows: 

a.  Fleet  end-user  acceptance; 

b.  STOW  97  acceptance; 

c.  ED-1  acceptance; 

d.  Marginal  ED-1  acceptance; 

e.  Not  acceptable. 

A  summary  of  the  results  is  provided  in  table  7.  The  test  procedures  were  performed  by  utiliz¬ 
ing  both  the  MCSF  PVD  graphical  user  interface  as  well  as  voice  commands.  The  Command- 
Talk  voice  commands  were  about  90%  reliable  in  performing  the  task.  By  utilizing  MCSF 
physical  models  (AAVs,  LAVs,  etc.)  and  behavioral  models  (cover  and  conceal,  embark/de¬ 
bark,  direct/indirect  suppressive  fire,  and  indirect  fire),  MCSF  performed  movement  to  contact 
at  company  level  as  well  as  platoon  daylight  attack  with  reasonable  fidelity  that  satisfied  the 
MCSF  ED-1  goals. 


Table  7.  Marine  Corps  SF  ED-1  analysis  items. 


Capability 

Result 

Individual  Combatants 

Rifle  platoon 

Marginal  ED-1  acceptance 

Rifle  squad 

ED-1  acceptance 

60-mm  mortar  squad 

ED-1  acceptance 

M240  machine  gun  squad 

Marginal  ED-1  acceptance 

Assault  team  commanded  by  a  platoon  commander 

ED-1  acceptance 

Armor 

M1A1  tank  platoon 

ED-1  acceptance 

Light  Armored  Reconnaissance  (LAR)  section 

ED-1  acceptance 

LAR-M  (mortar)  section 

ED-1  acceptance 

LAR-AT  (Anti-Tank)  section 

ED-1  acceptance 

Mechanized 

AAV  platoon 

ED-1  acceptance 

LVT-C7  with  chase 

ED-1  acceptance 

TOW  CAAT  teams 

ED-1  acceptance 

TOW  section 

ED-1  acceptance 

LVT-R7 

ED-1  acceptance 
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Table  7.  Marine  Corps  SF  ED-1  analysis  items.  (Continued) 


Capability 

Result 

Individual  Combatants 

Air 

CH-53 

Marginal  ED-1  acceptance 

CH-46 

Marginal  ED-1  acceptance 

AH-1 

ED-1  Acceptance 

AV8B 

Marginal  ED-1  acceptance 

4.  Air  Force.  During  the  STOW  Engineering  Demonstration  #1  (ED-1)  in  October  1995,  AFSF 
demonstrated  the  A-10,  F-16C,  and  FAC  in  the  CAS  role,  and  the  F-16C  in  the  AI  role.  The 
A- 10  and  F-16C  flew  the  correct  airspeed  and  altitude  during  ingress  and  egress,  but  airspeed 
changed  to  292  kn  during  the  attack  phase.  It  was  learned  that  a  separate  instruction  was  used 
for  attack  speed  in  the  attack  command,  and  this  was  changed  to  reflect  the  aircraft’s  route 
speed.  Later  evaluation  showed  that  changes  to  the  attack  command  corrected  the  airspeed 
problem.  The  F-16Cs  tasked  to  fly  low  level  at  500  ft  and  480  Kn  crashed  into  the  ground  on 
several  occasions.  A- 10s  flying  at  500  ft  and  250  Kn  did  not  experience  the  same  problem. 
When  the  F-16Cs  were  flown  using  “contour  flying,”  the  F-16Cs  did  not  crash.  LADS  investi¬ 
gated  the  problem  and  found  that  “low-level”  and  “nap-of-the-earth”  flying  methods  use  the 
same  algorithm  that  samples  the  terrain  skin  at  intervals  that  are  too  far  between  for  hilly  ter¬ 
rain  and  the  fast  airspeed  of  the  F-16C.  Both  aircraft  had  difficulty  acquiring  targets.  Most  of 
the  Initial  Point  to  target  runs  resulted  in  the  aircraft  overflying  the  target  because  it  did  not  see 
the  target  prior  to  reaching  it.  This  was  mostly  due  to  the  low  attack  profile  and  the  fact  that 
the  targets  were  dug  in  behind  the  terrain.  Attack  altitude  was  raised  250  ft  but  this  was  not 
enough  to  significantly  increase  target  acquisition.  LADS  looked  into  the  visual  sensor  param¬ 
eters  and  increased  the  field-of-view.  More  targets  were  seen  after  this,  but  there  were  still 
problems  in  hilly  terrain.  The  visual  model  is  one  of  several  sensor  models  to  be  reworked  by 
the.ModSAF  community.  Future  evaluations  will  be  deferred  until  the  sensor  models  are 
reworked.  The  weapons  sever  was  not  used  by  AFSF.  The  AMG-65  Maverick  employed  by 
the  A-10  and  F-16C  often  hit  short  of  the  target.  The  cause  could  not  be  determined,  and  eval¬ 
uation  was  not  completed  because  we  plan  to  transition  to  the  weapons  server  for  missile  sup¬ 
port,  including  the  Maverick.  However,  when  hits  did  occur,  damage  to  tanks  was  low  and  no 
kills  could  be  made  against  NRaD  vehicles.  The  Maverick  should  have  a  higher  probability  of 
kill  (Pk)  when  hits  occur.  Since  the  target  determines  the  amount  of  damage,  the  target  dam¬ 
age  model  for  tanks  and  vehicles  should  be  reviewed.  The  F-16  in  the  AI  role  successfully 
demonstrated  that  it  could  deliver  bombs  on  a  set  of  coordinates  or  be  tasked  to  attack  OPFOR 
tanks,  16  using  their  threat  assessment  and  target  acquisition  process. 

3.2.1. 2  Synthetic  Environment.  The  following  paragraphs  describe  SE  results  from  the  SE  per¬ 
spective.  IFOR  reported  the  synthetic  environment  (smoke,  etc.)  had  no  effect  on  IFOR  entities  or 
behavior.  Two  scenarios  were  demonstrated  by  SE  from  TEC  over  the  AAI/ATDNet  in  an  unclassi¬ 
fied  status  for  Day  1  of  ED-1.  There  were  five  sites  in  addition  to  TEC  that  participated  or  viewed 
these  scenarios:  NRaD,  NRL,  IDA,  ARL:UT,  and  DARPA.  This  demonstration  sequence  was  a 
deviation  from  the  planned  demonstrations  in  that  the  network  required  more  work  to  prepare  it  for 
the  high  entity  counts.  The  purpose  of  the  first  scenario  was  to  showcase  the  many  features 
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introduced  by  SE  to  the  STOW  program,  and  correctly  visualize  these  events  using  ModStealth. 
ModStealth  is  a  RITN  interface  between  ModSAF  and  a  CIG.  For  ED-1,  the  CIG  used  throughout 
was  VistaWorks.  Other  CIGs  are  expected  to  be  connected  to  ModStealth  to  compare  and  analyze 
the  strengths  and  weakness  of  each  platform.  Overall,  the  first  day  of  ED-1  was  considered  highly 
successful  by  demonstrating  the  work  introduced  by  SE  to  the  STOW  community  and  interfacing 
with  all  the  outlying  sites  participating  in  the  demonstration  using  the  new  RITN  code. 

1 .  The  first  scenario  consisted  of  four  vignettes: 

a.  Breaching  exercises,  examples  of  pre-emplaced  dynamic  terrain  objects,  flares,  and 
smoke;  visualization  of  weather  events 

b.  Weather  impacts  on  entity  behaviors; 

c.  Survivability  positions; 

d.  Destruction  of  pre-emplaced  dynamic  terrain  objects. 

TEC  served  as  the  weather  master  for  this  scenario  and  initiated  all  the  events  that  were 
observed  by  the  other  sites.  Tables  8  through  11  show  the  individual  events  and  results  during 
each  vignette  of  the  first  scenario. 


Table  8.  First  scenario,  first  vignette. 


Event 

Results 

Time  of  day 

Highly  successful.  The  visual  rendering  of  discrete  time  changes  from 
pre-dawn  to  the  afternoon  was  correct. 

Signal  flares 

Highly  successful.  The  three  colors  were  visible:  red,  green,  and  white. 
The  visual  rendering  in  the  pre-dawn  hours  was  correct. 

Illumination  flares 

Highly  successful.  The  three  colors  were  visible:  red,  green,  and  white. 
The  visual  rendering  in  the  pre-dawn  hours  was  correct. 

Concealment  smoke 

Highly  successful.  A  barrage  of  white  phosphorus  smoke  was  fired  on 
the  enemy  side  of  the  anti-tank  ditch  to  conceal  the  location  and 
movement  of  Blue  Forces.  The  visual  rendering  in  daylight  was  correct. 

Signal  smoke 

Highly  successful.  The  four  colors  were  visible:  red,  green,  yellow,  and 
violet.  The  visual  rendering  in  daylight  was  correct. 

Minefield  breaching, 
and  battlefield  smoke 

Highly  successful.  A  Bradley  fighting  vehicle  was  set  on  a  track  to  show 
the  existence  of  the  minefield,  and  battlefield  smoke  was  shown  as  a 
result  of  a  catastrophic  kill.  The  Grizzly  was  used  to  breach  the  minefield 
and  mark  the  lane.  The  AVLB  was  used  to  transit  the  minefield  via  the 
marked  lane. 

Destruction  of 
concertina  wire 

Highly  successful.  Pre-emplaced  concertina  wire  was  correctly 
visualized  by  all  sites.  The  wire  was  blown  in  the  vicinity  where  the  AVLB 
was  to  lay  its  bridge. 
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Table  8.  First  scenario,  first  vignette.  (Continued) 


Event 

Results 

Anti-tank  breaching 

Highly  successful.  The  anti-tank  ditch  was  correctly  visualized  by  all 
sites.  An  AVLB  was  used  to  breach  the  anti-tank  ditch.  After  the  bridge 
was  detached  from  the  AVLB,  the  AVLB  successfully  crossed  the  bridge. 

Simulation  of  a  dust 
storm 

Highly  successful.  The  weather  condition  was  reset  from  rural  condition 
with  60-km  visibility,  to  a  dust  storm.  The  visual  rendering  was  correct, 
showing  the  restricted  visibility  across  the  terrain. 

Simulation  of  a  rain 
storm 

Highly  successful.  The  weather  condition  was  reset  from  a  dust  storm  to 
several  incremental  changes  in  rain  intensities.  The  visual  rendering  was 
correct,  showing  the  restricted  visibility  across  the  terrain  as  the  rain 
intensities  increased,  then  decreased. 

Simulation  of  a  wind 
shift  and  change  in 
wind  speed 

Highly  successful.  The  wind  direction  was  shifted  and  the  wind  speed 
increased.  The  visual  rendering  was  correct,  showing  the  plumes  from 
the  concealment  smoke  and  battlefield  smoke  shifting  direction  and 
flattening  out  as  the  wind  speed  increased. 

Simulation  of  haze 

Highly  successful.  The  weather  condition  was  reset  from  rainy 
conditions  with  restricted  visibility  to  a  rural  hazy  condition  with  5-km 
visibility.  The  visual  rendering  was  correct,  showing  the  restricted  visibility 
across  the  terrain. 

Table  9.  First  scenario,  second  vignette. 


Event 

Results 

Time  of  day  and 
weather  state 

Highly  successful.  The  weather  condition  was  set  to  a  rural  hazy 
condition  with  5-km  visibility  in  the  afternoon  hours.  The  visual  rendering 
was  correct,  showing  the  restricted  visibility  across  the  terrain. 

Platoon  of  T72s  set 

1  km  from  a  platoon  of 
M1s 

Highly  successful.  The  firing  permission  for  each  platoon  was  set  to 
hold.  TEC  used  the  unit  editor  to  confirm  that  each  of  the  vehicles  could 
see  the  opposing  force.  No  firing  took  place. 

Simulation  of  a  fog 
affecting  tank 
behaviors 

Highly  successful.  The  weather  condition  was  reset  to  a  foggy  condition 
with  0.2-km  visibility.  The  visual  rendering  was  correct,  showing  the 
restricted  visibility  across  the  terrain.  After  about  30  sec,  none  of  the 
vehicles  could  sense  the  location  of  the  opposing  force.  The  firing 
permission  of  both  platoons  was  set  to  free  and  no  battle  engagement 
between  them  occurred. 

Simulation  of 
unrestricted  visibility 

Highly  successful.  The  weather  condition  was  reset  to  a  rural  condition 
with  60-km  visibility.  The  visual  rendering  was  correct,  showing  the 
unrestricted  visibility  across  the  terrain.  After  about  30  sec,  the  vehicles 
could  sense  the  location  of  the  opposing  force,  and  they  engaged  in 
battle. 
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Table  10.  First  scenario,  third  vignette. 


Event 

Results 

Time  of  Day  and 
weather  state 

Highly  successful.  The  weather  condition  was  set  to  a  rural  condition 
with  60-km  visibility  in  the  afternoon  hours.  The  visual  rendering  was 
correct,  showing  unrestricted  visibility  across  the  terrain. 

Two  T72s  set  near  a 
survivability  position 

Highly  successful.  The  survivability  position  is  a  pre-emplaced  dynamic 
terrain  object.  One  of  the  two  T72s  was  given  a  move  order  along  a  path 
that  led  the  tank  into  the  correct  position  within  the  dugout.  The  other 
tank  was  ordered  to  move  along  side. 

Battle  engagement 
with  Mis. 

Highly  Successful.  A  platoon  of  Mis  were  ordered  to  travel  cross 
country  to  engage  the  T72s  in  battle.  There  were  several  catastrophic 
kills,  and  battlefield  smoke  ensued  from  the  burning  vehicles. 

Table  11 .  First  scenario,  fourth  vignette. 


Event 

Results 

Time  of  Day  and 
weather  state 

Highly  successful.  The  weather  condition  was  set  to  a  rural  condition 
with  60-km  visibility  in  the  afternoon  hours,  showing  unrestricted  visibility 
across  the  terrain. 

Two  Mis  positioned 
on  a  road  in  the  midst 
of  the  buildings 

Highly  successful.  The  buildings  are  pre-emplaced  dynamic  terrain 
objects  that  are  destroyable.  Two  tanks  were  placed  on  a  road  in  the 
midst  of  these  multistate  objects.  The  visual  rendering  was  correct. 

Detail  of  the  buildings 

Highly  successful.  Zooming  in  on  the  buildings  revealed  the  detail  of  the 
buildings,  including  door  knobs  and  drapes,  and  detailed  siding  and 
roofing.  The  visual  rendering  was  correct. 

Destruction  of  the 
buildings 

Highly  successful.  The  Mis  were  ordered  to  perform  a  road  march 
through  the  town.  As  they  moved  from  the  buildings,  each  of  the  five 
buildings  were  destroyed  using  500-pound  bombs  from  the  artillery 
editor.  Each  building  that  was  destroyed  exhibited  a  fire  and  detailed 
debris  from  the  destruction.  The  visual  rendering  was  correct. 

2.  The  second  scenario,  called  the  Samarian  Trench,  was  to  integrate  many  of  the  features  that  SE 
introduced  to  STOW,  and  to  demonstrate  the  SE  work  in  a  distributed  environment.  This  sce¬ 
nario  was  also  modeled  after  a  previous  live  exercise  at  the  National  Training  Center  (NTC). 
The  results  of  this  scenario  were  highly  successful,  though  there  was  one  notable  exception 
that  has  been  corrected.  During  the  scenario,  after  the  AVLB  bridges  were  successfully  laid 
across  the  anti-tank  ditch,  there  were  a  number  of  vehicles  that  tracked  directly  toward  the 
anti-tank  ditch  and  fell  into  the  ditch,  rather  than  correctly  laying  a  route  to  the  other  side  of 
the  ditch  via  the  AVLB  bridges.  Several  other  vehicles  did  make  the  correct  route  across  the 
bridges  and  successfully  crossed  the  anti-tank  ditch.  A  patch  for  ModSAF  to  correct  this  rout¬ 
ing  problem  was  made  available  the  morning  of  the  exercise,  but  a  decision  was  made  at  TEC 
not  to  make  the  change.  This  last-minute  patch  was  not  tested  over  the  net,  and  it  was  not 
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known  whether  there  would  be  any  other  ill  effects  on  the  program  by  making  this  change. 
This  patch  has  since  been  tested,  and  the  scenario  now  works  properly. 

3.  The  Samarian  Trench  scenario  was  divided  into  four  segments: 

a.  Breaching  force; 

b.  Assault  force; 

c.  Overwatch  force; 

d.  Opposing  force. 

TEC  was  the  weather  master  for  this  scenario,  and  controlled  the  breaching  force.  NRaD  con¬ 
trolled  the  opposing  forces,  IDA  controlled  the  overwatch  forces,  and  ARLrUT  controlled  the 
assault  forces.  Table  12  shows  the  individual  events  during  the  course  of  the  Samarian  Trench 
Scenario. 


Table  12.  Second  scenario,  the  Samarian  Trench. 


Event 

Results 

Time  of  day 

Highly  successful.  The  visual  rendering  of  the  afternoon  was  correct. 

Signal  smoke  initiating 
behaviors 

Highly  successful.  Red  and  green  signal  smoke  was  used  to  initiate  the 
breaching  force’s  missions.  The  visual  rendering  of  the  signal  smoke  in 
daylight  was  correct. 

Concealment  smoke 

Highly  successful.  A  barrage  of  white  phosphorus  smoke  was  fired  on 
the  enemy  side  of  the  anti-tank  ditch  to  conceal  the  location  and 
movement  of  Blue  Forces.  The  visual  rendering  in  daylight  was  correct. 

Minefield  breaching 

Highly  successful.  Two  Grizzlies  were  used  to  breach  the  minefield,  and 
no  lane  markers  were  used.  The  Grizzlies  were  followed  by  AVLBs,  and 
later  by  other  Grizzlies  and  the  assault  forces.  One  of  the  AVLBs  did 
encounter  a  mine  and  suffered  a  catastrophic  kill.  This  illustrates,  that 
despite  the  Grizzly  clearing  a  lane  through  the  mine  field,  there  is  a 
measure  of  failure  that  is  taken  into  account  within  ModSAF. 

Anti-tank  breaching 

Highly  successful.  The  anti-tank  ditch  was  correctly  visualized  by  all 
sites.  An  AVLB  that  successfully  crossed  the  minefield  was  used  to 
breach  the  anti-tank  ditch.  After  the  bridge  was  detached  from  the  AVLB, 
the  AVLB  moved  to  the  side  of  the  bridge  to  allow  the  follow-on  Grizzlies 
and  assault  force  to  move  over  the  bridge. 

Simulation  of  an 
advancing  squall  line 

Highly  successful.  The  weather  condition  was  reset  from  rural  condition 
with  60-km  visibiiity,  to  a  dust  storm,  to  simulate  the  approach  of  a  squall 
line.  The  visual  rendering  was  correct,  showing  the  restricted  visibiiity 
across  the  terrain. 

Simulation  of  a  squall 
line  with  rain 

Highly  successful.  The  weather  condition  was  reset  from  a  dust  storm  to 
several  incremental  changes  in  rain  intensities,  simulating  the  passage  of 
the  squall  line.  The  visual  rendering  was  correct,  showing  the  restricted 
visibility  across  the  terrain  as  the  rain  intensities  increased,  then 
decreased. 
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Table  12.  Second  scenario,  the  Samarian  Trench.  (Continued) 


Event 

Results 

Simulation  of  a  squall 
line  passage  with  fog 

Highly  successful.  The  weather  condition  was  reset  from  rainy 
conditions  with  restricted  visibility,  to  fog  with  0.2-km  visibility,  simulating 
restricted  visibility  behind  the  squall,  and  in  advance  of  a  front.  The  visual 
rendering  was  correct,  showing  the  restricted  visibility  across  the  terrain. 

Simulation  of 
unrestricted  visibility 
and  a  wind  shift  and 
change  in  wind  speed 
after  frontal  passage 

Highly  successful.  The  weather  condition  was  reset  from  foggy 
conditions  with  restricted  visibility,  to  a  rural  condition  with  60-km 
visibility.  The  visual  rendering  was  correct,  showing  the  unrestricted 
visibility  across  the  terrain.  The  wind  direction  was  shifted  and  the  wind 
speed  increased.  The  visual  rendering  was  correct,  showing  the  plumes 
from  the  concealment  smoke  and  battlefield  smoke  shifting  direction,  and 
flattening  out  as  the  wind  speed  was  increased. 

Passage  of  the 
assault  forces  through 
adverse  terrain 
objects 

Successful.  Some  of  the  assault  forces  managed  to  correctly  route  their 
tracks  over  the  AVLB  bridges,  and  through  the  minefields,  others  fell  into 
the  anti-tank  ditch  and  were  disabled.  As  a  result,  the  anti-tank  ditch 
proved  to  be  a  formidable  impediment  to  the  Blue  Force’s  advancement. 

Battle  engagement 
between  Blue  and 

Red  Forces 

Successful.  The  Blue  Forces  that  managed  to  cross  the  anti-tank  ditch 
did  engage  in  battle  with  the  Red  Forces  with  some  success.  Both  tanks 
and  dismounted  infantry  on  the  opposing  force  were  engaged  with  the 

Blue  Forces.  Because  of  the  failure  of  several  Blue  Force  tanks  not 
routing  around  the  anti-tank  ditch  properly,  the  number  of  tanks  left  to 
engage  the  Red  Forces  were  drastically  reduced. 

Behaviors 

The  following  subparagraphs  are  the  behaviors  observed  for  each  of  the  technology  areas. 


3.2.2.1  Army.  The  behaviors  for  the  Army  are  presented  separately  as  CFOR,  IFOR,  and  Army. 

1 .  Command  Forces  (CFOR)  are  virtual  military  decision  makers  and  are  being  developed  to  pro¬ 
vide  a  Command  and  Control  (C^)  capability  within  the  DARPA  Synthetic  Forces  Program  to 
support  the  STOW  97.  CFOR  will  interact  (exchange  information)  hierarchically  through  a 
CCSIL  that  will  represent  the  C^  information  exchange.  The  Command  Entity  (CE)  demon¬ 
strated  in  ED-1  consisted  of  an  Army  Company  Team  Commander  developed  by  Science 
Applications  International  Corporation  (SAIC).  Also  demonstrated  was  the  Army  Forward 
Observer  (FO)  developed  by  Applied  Research  Laboratories  at  the  University  of  Texas. 
Although  the  FO  is  not  considered  a  CE,  it  is  being  developed  under  the  CFOR  Program  to 
provide  the  underlying  capabilities  to  support  other  fire  support  CEs  (e.g.,  FIST,  Bn  FSE). 
Hughes  Research  Laboratories  (HRL)  was  originally  scheduled  to  participate  in  ED-1,  but  a 
decision  was  made  before  ED-1  to  have  them  participate  in  a  later  demonstration  in  December 
due  to  their  development  efforts  not  being  at  the  level  required  for  ED-1  participation.  The 
following  paragraphs  summarize  the  objectives  and  results  of  ED-1.  A  detailed  description  of 
the  results  and  problems  encountered  is  provided  below. 

a.  CFOR  Objectives.  The  objectives  of  the  CFOR  Program  during  ED-1  were  to  demon¬ 
strate  the  following: 
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(1)  Two  Army  Company  Team  Commanders  conducting  a  virtual  Field  Training  Exer¬ 
cise  (vFTX)  in  Attack  scenarios; 

(2)  An  FO  acquiring  and  evaluating  targets  that  come  into  its  field  of  regard; 

(3)  Reasonable  behavior  on  the  part  of  the  Company  Team  Commander  from  both  a 
planning  and  reactive  standpoint  as  METT-T  factors  are  varied; 

(4)  The  ability  to  send  and  receive  the  proper  CCSIL  messages. 

b.  CFOR  Measures  of  Success.  The  primary  measure  of  success  for  the  CFOR  Program  was 
for  the  Company  Team  Commander’s  and  FO’s  behaviors  to  be  deemed  reasonable  within 
the  constraints  of  ModSAF  by  SMEs.  Behavior  for  a  vFTX  Attack  mission  must  be  rea¬ 
sonable  from  both  a  planning  and  reactive  standpoint.  Mission,  Enemy,  Terrain,  Troops 
available,  and  Time  (METT-T)  factors  will  influence  and  prompt  the  Commander  to  eval¬ 
uate  his  situation  and  possibly  initiate  a  state  change.  The  scenario  for  the  FO  was 
designed  to  be  more  simplistic  in  nature  and  demonstrate  only  reactive  behavior. 

c.  Company  Team  Commander  Analysis.  Overall,  the  participation  of  CFOR  in  ED-1  was  a 
success.  ED-1  was  the  first  opportunity  for  the  CFOR  team  to  demonstrate  CFOR  devel¬ 
opment  to  the  STOW  community.  During  ED-1,  the  CFOR  team  successfully  demon¬ 
strated  two  CFOR  virtual  company/team  commanders  (SAIC  software)  operating  in  a  tac¬ 
tical  environment  alongside  an  operator-controlled  ModSAF  company  in  a  virtual  training 
exercise.  The  CFOR  company  coimnanders  received  a  task  force  order,  parsed  the  order 
to  identify  areas  relevant  to  their  respective  company,  conducted  mission  analysis  (to 
include  METT-T),  and  developed  courses  of  action  that  they  formatted  into  company- 
level  CCSIL  orders.  They  then  sent  these  orders  to  the  task  force  commander  (simulating 
a  briefback  process)  for  approval.  Once  the  task  force  conunander  approved  the  company 
orders,  the  CFOR  companies  executed  these  plans.  During  execution,  the  CFOR  compa¬ 
nies  reacted  to  unexpected  enemy  contact.  The  SAIC  CE  code  generates  both  company- 
and  platoon-level  reactions  to  unexpected  enemy  contact  based  upon  the  size,  etc.,  of  the 
enemy  force  (using  a  table  in  the  “Actions  On  Contact”  module  of  the  CE  code).  During 

,  ED-1,  the  entire  company  would  execute  the  new  plan  generated  by  the  Company  Com¬ 
mander  when  an  unexpected  enemy  was  contacted.  After  ED-1  it  was  determined  that 
there  was  a  problem  in  the  CE  code  that  decides  which  type  of  actions  on  contact  to  per¬ 
form,  thereby  causing  the  entire  company  to  be  tasked  to  perform  the  actions  on  contact 
every  time,  rather  than  generating  platoon-level  reactions  when  required.  Once  this  con¬ 
tact  was  completed,  the  company  team  went  back  to  complete  the  original  plan  from  the 
point  the  unexpected  contact  occurred.  The  two  CFOR  companies  required  little  operator 
intervention  once  the  battalion  order  was  issued.  There  were  incidents  when  the 
CCSIL_SAF  vehicles  ran  into  unexpected  terrain  (wadi)  that  caused  movement  problems 
for  them.  Operator  intervention  was  required  to  move  the  vehicles  to  the  other  side  of  the 
terrain  feature.  This  same  problem  was  initially  encountered  by  the  ModSAF  unit  and 
was  fixed  after  TEC  provided  a  patch  to  the  ModSAF  software.  However,  the  CFOR 
team  was  unable  to  incorporate  the  fix  into  CCSIL_SAF  due  to  the  difficulty  of  ftping 
files  and  compiling  software  in  the  IDA  classified  environment.  The  CFOR  virtual  com¬ 
mander  was  able  to  demonstrate  reasonable  behavior  both  in  planning  and  execution  dur¬ 
ing  ED-1  as  deemed  by  Scott  Carey,  the  Logicon  RDA  SME  witnessing  the  ED-1  demon¬ 
stration.  Refinement  is  needed  to  improve  behavior;  however,  the  plans  generated  were 
acceptable,  given  the  METT-T  encountered.  The  plans  generated  and  actions  taken  were 
acceptable  under  the  circumstances.  Overall,  the  behavior  of  the  CFOR-directed 
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companies  would  have  looked  better  had  it  not  been  for  some  flawed  behaviors  inherent 
to  ModSAF.  The  SAIC  Company  Team  Commander  was  able  to  demonstrate  the  ability 
to  send  and  receive  various  CCSIL  messages.  The  following  were  demonstrated:  the  pro¬ 
cessing  of  a  Bn  OPORD,  the  creation  of  a  subsequent  Co  OPORD,  the  entire  briefback 
process,  the  request  of  a  SITREP  from  platoons,  the  process  of  incoming  SITREPs,  and 
the  processing  of  new  Co  OPORD/FRAGO  when  unexpected  enemy  contact  or  obstacles 
would  result  in  a  situation  where  a  new  plan  was  required. 

d.  Problem  Areas  Identified.  The  following  items  provide  an  overview  of  problems  encoun¬ 
tered  and  the  status  of  actions  taken. 

(1)  Some  ModSAF  task  frames  lack  clearly  defined  end  points,  therefore,  the 
CCSIL_SAF  unit  required  prodding  from  the  ModSAF  GUI  to  move  to  the  next  task. 
This  problem  is  currently  being  addressed  by  MITRE.  However,  these  problems  are 
also  being  provided  to  STRICOM  for  future  fixes/enhancements  in  ModSAF. 

(2)  When  the  unit  completed  its  reaction  to  unexpected  contact,  the  company  commander 
would  do  a  replan  from  the  “task”  it  was  performing  when  it  was  interrupted.  The 
commander  does  not  do  the  replan  from  the  geographic  place  where  interrupted,  but 
rather  the  ARTEP  task  where  interrupted.  This  resulted  in  a  situation  where  the  com¬ 
pany  commander,  after  reacting  to  an  enemy  before  in  the  attack  position,  tried  to  go 
back  to  the  attack  position.  This  problem  is  being  addressed  and  will  be  further  eva¬ 
luated  in  future  vFTX  testing. 

(3)  The  functionality  that  allows  the  platoons  to  develop  the  situation  until  they  get  to  the 
point  where  company-level  action  is  required  was  incorporated  into  the  SAIC  code. 
However,  the  bug  mentioned  above  prevented  it  from  being  invoked. 

(4)  ModSAF  vehicles  were  unable  to  traverse  the  wadis  due  to  the  steep  slopes  on  their 
edges.  Both  companies  were  frequently  getting  stuck  and  had  to  be  manually  moved 
to  another  location  before  the  remaining  vehicles  could  continue  with  the  mission 
provided  to  them  by  their  commander.  As  there  were  several  such  problematic  wadis 
in  the  third  Attack  vignette,  a  decision  was  made  to  demonstrate  the  first  and  second 
vignettes,  and  then  return  to  the  first  vignette  with  the  addition  of  more  unexpected 
enemy  vehicles.  Just  prior  to  Day  4  of  ED-1,  TEC  provided  a  fix  to  the  ED-1  version 
of  ModSAF  to  help  the  vehicles  traverse  the  wadis.  However,  as  the  CFOR  Program 
uses  CCSIL_SAF,  and  integration  and  development  tools  were  not  readily  available 
at  IDA,  the  CFOR  team  was  unable  to  incorporate  this  fix  before  ED-1. 

(5)  Multiple  CCSIL_SAF  back-ends  for  the  two  CFOR  companies  would  cause  one  of 
the  back-ends  to  go  down,  in  turn,  causing  the  CE  to  go  down.  The  ED-1  vignettes 
were  eventually  run  with  the  companies  running  on  only  one  CCSIL_SAF  back-end. 
The  CFOR  team  has  been  unable  to  duplicate  this  problem  at  MITRE,  but  will  try  to 
duplicate  it  again  during  the  December  demonstration  of  Hughes  Research  Laborato¬ 
ries’  CEs  at  IDA. 

(6)  A  memory  overwrite  problem  in  CCSIL_SAF  was  caused  by  allowing  the  CE  to 
generate  routes  with  more  than  109  data  points.  This  caused  the  Persistent  Object 
(PO)  packet  size  limit  of  1599  bytes  to  be  exceeded.  A  workaround  was  developed 
for  ED-1.  The  real  solution  to  this  problem  needs  further  investigation  by  the 
CFOR  team. 
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(7)  An  additional  memory  overwrite  problem  in  CCSIL_SAF  was  caused  by  libgenradio. 
Each  Signal  PDU  contains  an  application-specific  ID  that  serves  as  an  identifier  for 
the  contents  of  the  data  portion  of  the  PDU.  ModSAF  1.5.1  had  a  bug  in  libgenradio 
that  caused  it  to  copy  a  fixed  amount  of  data  from  each  Signal  PDU  into  memory 
before  checking  the  ID  to  determine  how  much  data  needed  copying.  This  caused 
problems  when  the  Signal  PDU  contained  a  CCSIL  message  having  less  data  than  the 
fixed  amount  being  copied  by  libgenradio.  This  bug  has  been  fixed  in  ModSAF  2.0, 
but  another  problem  was  introduced.  The  application-specific  ID  reserved  for  CCSIL 
messages  (  =  1 )  is  now  apparently  also  used  for  other  purposes  in  ModSAF.  This 
problem  was  not  resolved. 

e.  FO  Analysis.  From  the  Fire  Support  point-of-view,  the  FO’s  vignette,  although  not  com¬ 
plex,  was  considered  successful.  ARL:UT  demonstrated  the  ability  to  provide  planned 
enhancements  and  a  reimplemenation  of  rulesets  from  their  existing  FSATS  simulation  to 
produce  a  working  When  Ready  Fire  for  Effect  mission  thread.  The  FO  could  identify 
enemy  vehicle/forces  entering  its  field-of-view,  and  generate  a  “when  ready  fire  for  effect: 
fire  request  message.”  The  FO  included  in  the  exercise  was  able  to  use  the  visual  library 
features  of  ModSAF  to  acquire  the  targets  that  came  within  its  field  of  regard  in  the 
appropriate  (expected)  manner.  Terrain  masking  was  taken  into  account  correctly.  The 
FO  also  correctly  evaluated  each  target  presented  for  proper  attackability  criteria,  and  pro¬ 
duced  the  routine  fire  requests  anticipated  (future  options  will  eventually  include  immedi¬ 
ate  fire  requests  and  intelligence  messages).  The  CCSIL  (When  Ready  Fire  For  Effect) 
Fire  Request  messages  sent  by  the  FO  were  generated  properly.  The  messages  were 
picked  up  not  only  by  the  monitor  running  on  the  local  ModSAF  session,  but  were  also 
picked  up  by  the  CFOR  monitor  running  on  the  network  to  support  the  Ground  Maneuver 
vignettes.  The  FO’s  vignette  took  place  in  the  NW  comer  of  the  GMB  to  avoid  confusion 
with  the  ground  maneuver,  dismounted  infantry,  and  RWA  vignettes.  Unfortunately,  the 
ModStealth  terrain  in  this  area  was  not  viable  and,  therefore,  the  realism  of  the  target 
acquisition  could  not  be  viewed  with  the  Stealth.  Because  it  was  undesirable  to  have  any 
of  the  other  entities  unexpectedly  engage  the  target  that  was  generated  for  the  FO  vignette, 

•  and  because  the  target  acquisition  capabilities  could  be  viewed  on  the  ModSAF  PVD,  the 
FO  vignette  was  not  moved  to  another  location. 

2.  IFOR.  At  the  multivehicle  behavior  level,  the  focus  in  ED-1  was  on  teams  and  companies  of 
AH-64  Apache  attack  helicopters.  The  specific  list  of  relevant  behaviors  can  be  found  as  part 
of  the  overall  list  of  behavioral  capabilities  outlined  in  sections  5  and  6.  The  results  of  behav¬ 
ioral  testing  can  be  suimnarized  as  follows: 

a.  Successfully  completed  all  five  planned  vignettes,  while  varying  the  mission  (armed 
reconnaissance  and  attack),  company  and  team  stmcture,  terrain,  formation,  and  target 
prioritization.  These  vignettes  were  generally  consistent  with,  but  not  in  coordination 
with,  the  overall  Army  scenario. 

b.  Demonstrated  some  behaviors  that  were  unexpected  (such  as  an  armed  reconnaissance 
mission,  variations  in  team  and  company  sizes,  robustness  of  formation  flying  under  death 
of  company  members,  and  variations  in  target  prioritization). 

c.  Additional  KA  is  required  to  help  determine  better  general  criteria  for  such  things  as  the 
height  of  a  popup  attack,  when  to  terminate  a  popup  before  reaching  the  planned  height, 
and  when  to  leave  a  battle  position  and  return  to  the  FARR 
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d.  Successfully  demonstrated  the  beginnings  of  an  RWA  scout  capability  that  can  perform 
reconnaissance  and  provide  information  to  attack  helicopters  for  use  in  performing  their 
missions.  One  problem  that  showed  up  in  scout  behavior  was  that  the  scouts  would  never 
engage  targets  under  any  circumstances  during  attack  missions.  That  they  should  actually 
do  so  was  information  missing  from  the  pre-ED-1  KA. 

e.  Although  it  was  explicitly  not  a  focus  of  ED-1,  most  of  the  development  was  planned  for 
after  ED-1,  it  was  clear  that  there  were  significant  deficiencies  in  C^.  Some  capabilities  in 
this  area  were  observed  (for  example,  the  scouting  activity),  but  considerable  behavioral 
and  infrastructural  work  is  still  necessary  here.  One  of  the  most  significant  problems 
exhibited  in  ED-1  was  that  the  RWA  companies  could  not  adjust  appropriately  to  the 
death  of  a  key  player  (either  the  nominal  commander  or  a  key  scout  who  was  to  provide 
critical  information  to  the  rest  of  the  company),  though  they  could  adjust  to  the  death  of 
other  less-critical  group  members.  A  related  problem  was  that  attack  entities  did  not  com¬ 
municate  about  what  they  observed  so  as  to  fill  in  gaps  in  each  other’s  understanding  of 
the  situation.  This  occasionally  resulted  in  inappropriate  behavior  by  RWA,  unaware  of 
things  of  that  they  should  have  been  aware. 

f.  Also  not  planned  for  ED-1,  the  absence  of  a  remote  designation  for  Hellfires  (missiles) 
and  traveling  bounding  overwatch  was  definitely  noticeable  in  the  behavior.  These 
behaviors  were  (and  are)  planned  for  later. 

3.  Army.  The  following  items  are  presented  for  behaviors  in  terms  of  Strengths  and  Weaknesses. 

SE  is  also  included  here. 

a.  Strengths 

(1)  Generally  good  representation  of  the  battlefield; 

(2)  Placement  of  forces  adequate  and  realistic; 

(3)  New  systems  operated  well  after  operator  training  (AVLB,  Grizzley,  minefield 
breaching); 

.  (4)  Desert/SW  United  States  terrain  and  textures  were  generally  adequate; 

(5)  SE  was  generally  adequate  for  most  applications  in  this  scenario; 

(6)  Good  depiction  of  smoke,  fog,  vehicle  dust,  darkness,  and  rain; 

(7)  Dust  clouds  from  Mis  were  obvious; 

(8)  Formations  of  Mis  reacted  to  smoke  properly  (slowed  and  closed  formation)  after 
smoke  Mis  resumed  speed 

(9)  Smoke  was  observed  and  Mis  reacted  properly  to  an  ATGM  attack. 

b.  Weaknesses 

(1)  Red  should  have  wiped  out  Blue; 

(2)  Some  polygon  problems  (reverse  slope  hillsides,  etc.),  some  coarseness  in  terrain; 

(3)  Two  different  Terrain  Data  Bases  used  and  not  verified  prior; 

(4)  Stealth  was  incompatible  with  Data  Bases;  jitters,  vertical  blue  lines  in  some  views; 

(5)  Operators  often  selected  inappropriate  contour  line  resolution  and  got  in  trouble  as  a 
result; 
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(6)  Wide  variation  in  wire  and  ditch  visualization; 

(7)  AVLB  needed  more  work  to  eliminate  its  sensitivity  during  operator  inputs; 

(8)  More  nighttime  scenarios  need  to  be  played,  along  with  more  rain. 

3.2.2.2  Navy.  This  paragraph  describes  the  Navy  portion  of  behaviors.  Navy  behaviors  were  sepa¬ 
rated  into  IFOR,  Navy  Surface,  and  Navy  AirSAF  behaviors. 

1.  IFOR.  The  following  behaviors  were  observed  by  IFOR. 

a.  The  planes  successfully  completed  all  three  missions  (Defensive  Air,  Close  Air  Support, 
and  Combined  Strike).  Each  of  these  missions  included  a  variety  of  capabilities  includ¬ 
ing:  running  and  circling  rendezvous;  airborne  retanking;  communication  and  coordina¬ 
tion  between  control  entities  (E-2C,  FAC(A),  TACC,  TAD)  and  fighter  and  attack  planes; 
section-level  and  division-level  flying  and  attacks;  use  of  PGMs,  HARMs,  and  dumb 
bombs;  and  2v2  BVR  air-to-air.  This  was  the  IFOR  primary  goal  for  ED-1,  and  it  was 
achieved. 

b.  The  planes  could  respond  to  many  unexpected  interactions  in  the  scenarios  without  fail¬ 
ure.  For  example,  the  IFOR  CAS  mission  was  disrupted  by  an  unexpected  attack  from 
enemy  fighters.  This  was  not  expected  from  the  scenario.  (Some  unexpected  interactions 
did  result  in  nondoctrine  behavior  from  the  agents,  such  as  when  a  division  was  attacked 
by  10  planes.  However,  tactics  have  not  yet  been  encoded  for  4vN  engagements,  so  this 
was  not  a  surprise.) 

c.  The  terminal  targeting  of  many  of  the  IFOR  weapons  was  adversely  affected  by  the 
increased  CPU  load  (this  was  the  only  negative  effect  of  the  increased  load  on  the  CPU 
because  of  the  network).  Although  the  IFOR  planes  could  deliver  their  ordnance,  more 
than  once  they  were  unable  to  get  a  targeting  solution  on  their  first  run  at  a  target.  Code 
has  since  been  optimized  to  avoid  this  in  the  future. 

d.  During  air-to-air  intercepts  using  the  E-2C,  the  E-2C  and  the  fighters  need  to  switch  to 
close-control  for  planes  that  have  committed  to  an  attack.  It  was  discovered  that  the 
attacking  planes  would  get  distracted  by  broadcast  control  messages. 

2.  Navy  Surface.  During  STOW  ED-1,  Navy  SF  demonstrated  the  major  platform  systems  per¬ 
formance  (not  specific  behaviors)  for  a  CVBG  composed  of  an  Aegis  Cruiser  (CG-59),  a 
Guided  Missile  Destroyer  (DDG-51),  a  Destroyer  (DD-963),  an  Aircraft  Carrier  (CVN-68), 
and  a  Logistics  Ship  (AOE-6).  The  major  platform  systems  included  basic  operations  of  sen¬ 
sor  and  weapon  systems,  basic  maneuvering  operations,  and  damage  modeling  for  each  ship 
platform.  The  weapons  systems  included  a  DIS-capable  OS,  provided  by  NAWC-AD  for  high 
fidelity  flyout  of  the  missiles  launched  by  Navy  SF.  In  conjunction  with  the  CVBG,  there  was 
an  ATF  composed  of  amphibious  assault  ships  (LHD,  LSD,  and  LPD)  and  landing  craft 
(LCAC  and  LCU);  a  MCG  composed  of  mine  hunting  and  sweeping  platforms  and  entities 
(MCM,  MHC,  floating  mine,  sweep  gear);  an  OPFOR  SAG;  and  Navy  Air  assets  flown  by  the 
Air  SF  developers  (WISSARD).  The  ATF,  MCG,  and  OPFOR  SAG  did  not  yet  contain  their 
own  inherent  systems,  but  were  represented  by  the  major  systems  already  developed  for  the 
CVBG.  There  was  an  attempt  to  demonstrate  the  communications  between  an  SH-60  on  an 
OTH  surface-to-surface  engagement  mission,  flown  by  Air  SF,  and  a  Navy  SF  Aegis  Cruiser. 
These  actions  were  to  be  done  automatically  without  operator  intervention,  using  the  CFOR 
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CCSBL.,  which  packages  its  protocols  into  the  DIS  Signal  PDU.  This  Navy  CCSIL  prototype  is 

the  beginning  of  the  behavioral  representation  to  be  provided  by  Navy  CFOR  efforts. 

3.  Navy.  AirSAF.  The  following  behaviors  pertain  to  WISSARD  and  the  Navy  AirSAF. 

a.  Performed  an  OTH  targeting  mission  utilizing  an  SH-60  from  WISSARD  and  a  USN 
Aegis  cruiser  from  NRaD,  communicating  through  CCSIL-generated  messages.  The 
result  was  partially  sucessful.  This  event  could  only  occur  during  very  low  network  traf¬ 
fic  periods  and  was  successful  primarily  only  one  way.  The  WISSARD  SH-60  success¬ 
fully  received  the  mission  brief;  however,  the  Surface  Contact  Report  caused  the  Navy  SF 
to  crash  at  NRaD  due  to  incorrect  fields  in  the  received  PDU. 

b.  Utilized  a  remote  OS  application  located  at  a  geographically  distant  site  to  support  missile 
flyouts  initiated  by  another  site.  The  result  was  partially  successful.  A  Maverick  air-to- 
ground  missile  launched  from  a  WISSARD  F/A-18  was  successfully  flown  out  by  an  OS 
from  NRaD.  This  missile  scored  a  hit  on  the  target  it  was  employed  against  with  apparent 
lethal  damage.  Further  testing  for  different  weapons  was  not  performed  due  to  time  and 
hardware  constraints  at  both  sites. 

c.  Numerous  OPFOR  aircraft  from  WISSARD  attempted  to  attack  Navy  surface  ships  gen¬ 
erated  and  under  the  control  of  NRaD.  The  result  was  unsuccessful.  With  the  extremely 
high  lethality  of  the  missiles  and  Close  in  Weapons  System  (CIWS)  on  the  ships,  coupled 
with  the  very  limited  weapons  suite  and  nonexistent  defensive  behavior  of  the  OPFOR 
aircraft,  very  few  attackers  ever  reached  the  Blue  ships.  During  many  of  these  engage¬ 
ments,  it  appeared  weapons  from  the  ships  were  fired  at  ranges  greater  than  what  would 
be  possible  with  actual  hardware.  In  the  few  instances  where  OPFOR  aircraft  actually 
reached  Blue  ships,  the  aircraft  failed  to  employ  weapons  despite  free  permission  and 
acquisition  of  the  target  by  the  attacker.  The  cause  of  this  anomaly  could  not  be  deter¬ 
mined. 

d.  Embark  Individual  Combatants  generated  by  NRaD  onto  helicopters  generated  by  WIS¬ 
SARD  and  transport  them  via  a  route  to  a  different  geographic  location  then  disembark. 
The  result  was  partially  successful.  ICs  embarked  into  the  helicopters  and  were  success¬ 
fully  disembarked  at  the  prescribed  location.  Several  problems  that  were  observed  were 
the  parceling  of  ICs  in  a  location  other  than  the  helo  during  transport  and  the  erratic 
behavior  of  RWA  when  in  the  proximity  of  large  numbers  of  entities  such  as  ground 
vehicles  and  ICs.  In  the  first  case,  the  movement  of  the  IC  group  to  a  different  area  of  the 
TDB  resulted  in  an  unintended  engagement  between  Red  and  Blue  Forces.  If  this  mecha¬ 
nism  is  used,  a  better  method  to  hide  and  shield  these  “in-limbo”  entities  from  other  enti¬ 
ties  should  be  used.  The  inability  of  the  RWA  to  process  large  numbers  of  entities  when 
in  the  low-altitude  environment  caused  highly  erratic  behavior,  and  crashes  of  entities 
when  unable  to  quickly  and  accurately  process  all  the  information  being  presented  to  it. 
This  also  occurred  during  RWA  operations  with  IFOR  agents;  however,  the  resulting  out¬ 
comes  did  not  appear  to  be  quite  as  catastrophic. 

e.  Fixed  Wing  and  Rotary  Wing  aircraft  (IFOR  and  ModSAF)  generated  at  WISSARD 
executed  air-to-surface  attacks  on  ground  entities  generated  by  numerous  sites  with  vary¬ 
ing  results.  The  result  was  that  the  interactions  appeared  to  occur  properly  with  detection 
and  attack  of  targets  executed,  as  expected.  The  one  anomaly  in  these  interactions  that 
was  very  evident  was  the  probability  of  hit  and  probability  of  kill  percentages  that  were 
occurring.  It  appeared  an  inordinate  number  of  hits  would  occur  on  a  specific  target 
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without  incurring  any  damage.  Also,  several  times  during  high  network  load  periods, 
valid  shots  appeared  to  be  taken  that  would  not  guide  to  target  hits  despite  the  lack  of 
countermeasures  or  defensive  maneuvering.  In  summary,  from  a  historical  perspective  it 
appeared  that  with  a  valid  launch,  the  probability  of  a  hit  or  kill  was  much  lower  than 
expected. 

3.2.2.3  Marine  Corps.  When  performing  Movement  to  Contact  (MTC)  at  company  level,  the  fol¬ 
lowing  MCSF  behaviors  were  observed.  These  behaviors  were  embark/debark  and  general  attach¬ 
ment.  In  addition  to  these  behaviors,  the  general  ModSAF  behaviors  such  as  move,  attack,  and  react 
to  fire  were  observed.  The  execution  of  these  behaviors  were  acceptable,  but  because  some  of  the 
implementation  (in  ModSAF)  lacked  robustness,  they  were  rated  as  marginal  ED-1  acceptance. 
These  problems  were  identified  and  reported  (see  Appendix  A  PCRs).  For  example,  embark  and 
debark  behavior  worked  well,  but  a  PCR  was  written  because  embark/debark  only  worked  when  the 
task  was  performed  in  real  time  (hence  embark/debark  did  not  work  in  a  saved  scenario).  When  per¬ 
forming  a  Daylight  Attack  at  platoon  level,  the  following  MCSF  behaviors  were  observed.  These 
behaviors  were  as  follows: 

1.  IC  basic  formation; 

2.  IC  basic  movement; 

3.  IC  coordinated  movement; 

4.  IC  terminal  functions; 

5.  Tactical  use  of  terrain; 

6.  Single  envelopment  attack; 

7.  Usage  of  signal  flares; 

8.  Direct/indirect  suppressive  fire. 

Similar  problems  existed  for  Daylight  Attack  for  platoon  level  as  with  MTC.  For  example,  single 
envelopment  attack  worked  well  under  pocket  SAP  configuration,  but  under  distributive  environ¬ 
ment,  the  station  keeping  and  formation  functionality  were  sometimes  erratic.  The  analysis  results 
were  rated  as  in  paragraph  3.2. 1.1,  and  are  described  as  follows: 

1 .  IC  Basic  Formation  -  ED-1  acceptance; 

2.  IC  Basic  Movement  -  ED-1  acceptance; 

3.  IC  Coordinated  Movement  -  Marginal  ED-1  acceptance; 

4.  IC  Terminal  Functions  -  Marginal  ED-1  acceptance; 

5.  Tactical  Use  of  Terrain  -  Marginal  ED-1  acceptance; 

6.  Rifle  Squad/Platoon  Single  Envelopment  Attack  -  Marginal  ED-1  acceptance; 

7.  Embark/Debark  Capability  -  Marginal  ED-1  acceptance; 

8.  General  Attachment  Capabilities  -  ED-1  acceptance; 

9.  Usage  of  Signal  Flares  -  Marginal  ED-1  acceptance; 

10.  Reaction  to  Suppressive  Fire  -  Not  acceptable  (PCR  generated); 


38 


11.  Direct  Suppressive  Fire  -  Marginal  ED-1  acceptance; 

12.  Indirect  Suppressive  Fire  -  Marginal  ED-1  acceptance. 

3.2.2.4  Air  Force.  The  Forward  Air  Controller  (FAC)  worked  very  well.  The  FAC  passed  all  tar¬ 
get  information  properly  to  the  CAS  aircraft  via  radio  transmission  PDUs.  The  only  problem  noted 
was  when  an  aircraft  returned  to  the  contact  point  and  communicated  with  the  FAC,  the  aircraft.  The 
returning  aircraft  would  take  the  tasking  and  then  decide  if  it  could  fly  the  mission.  If  the  aircraft 
decided  it  could  not  fly  the  mission  due  to  lack  of  weapons,  low  fuel,  or  on-station  time  expired,  the 
tasking  was  not  returned  to  the  FAC.  The  CAS  aircraft  must  decide  if  they  can  fly  the  tasking  before 
taking  the  FAC  tasking.  Also,  the  FAC  must  be  reworked  to  allow  more  dynamic  changes  to  the 
tasking  after  the  aircraft  have  accepted  the  tasking,  such  as  having  the  aircraft  abort  the  mission  any¬ 
time  after  the  contact  point  up  to  weapons  release.  Aircraft  correctly  returned  to  home  base  upon 
reaching  end  of  on-station  time.  However,  aircraft  decisions  to  return  to  home  base  (due  to  BINGO 
fuel  or  lack  of  weapons)  could  not  be  tested.  CAS  aircraft  would  attack  the  closest  threat  and  not 
necessarily  the  target  assigned  by  the  FAC.  When  CAS  targets  are  assigned  by  the  FAC,  CAS  air¬ 
craft  should  not  attack  other  targets  unless  in  self  defense  or  within  the  Rules  Of  Engagement  (ROE) 
given  by  the  FAC.  Currently,  there  are  no  ROEs  given  by  the  FAC.  Both  the  A-10  and  the  F-16 
threat  assessment  needs  work.  However,  no  solution  was  implemented  because  behaviors  will  be 
done  by  SOAR,  and  not  Task  Frames,  in  the  future.  The  same  is  true  of  the  problems  noted  with 
formation  flying  by  the  A-10  and  F-16C. 

3.2.3  Synthetic  Forces  interoperability 

Synthetic  Forces  Interoperability  (SFI)  was  conducted  from  the  beginning  of  SSIT  #4  through 
ED-1  as  the  Test  Continuum. 

3.2.3.1  Army.  The  Army  SFI  has  been  reported  as  CFOR,  IFOR,  and  then  as  STRICOM’s  Army 
SF  as  shown  below. 

1.  CFOR.  Joint  interaction  between  CFOR  and  other  SF  was  achieved.  However,  planning  was 
done  at  the  human  level  only,  resulting  in  interactions  limited  to  the  battalion  commander 
(Scott  Carey)  requesting  CAS  missions  from  the  Air  Force.  Additional  enemy  vehicles  were 
added  near  the  two  Company  Team  Commander’s  objectives  to  avoid  having  the  Air  Force 
destroy  all  of  the  enemy  that  the  CFOR-directed  companies  would  encounter. 

2.  IFOR.  This  section  details  all  of  the  interactions  between  IFOR  FWA  and  RWA  and  other 
forces.  It  includes  overviews  of  both  FWA  and  RWA  missions,  the  interactions,  and  summa¬ 
ries. 

a.  FWA.  FWA  scenarios  all  involved  Navy  Air.  The  specific  airframes  demonstrated  were 
F/A-18  (Hornet),  F-14D  (Tomcat),  E-2C,  A-10  (FAC(A)),  and  KC-10  (tanker).  All  Navy 
Air  was  provided  by  Soar/IFOR  agents.  OPFOR  units  (both  ground  and  air)  were  con¬ 
trolled  by  ModSAF  behaviors.  OPFOR  units  were  not  evaluated  by  IFOR  personnel.  The 
entities  for  these  scenarios  (including  the  planned  OPFOR  entities)  were  all  generated 
during  ED-1  at  the  WISSARD  laboratory.  There  were  three  distinct  scenarios,  which 
were  then  followed  by  an  FWA  summary. 

(1)  Defensive  Air.  Defensive  Air  included  two  Blue  Section  BARCAP  in  depth  with  an 
E-2C  controller  and  a  tanker.  The  forward  CAP  was  attacked  by  a  Red  sweep  of 
MiG-29s,  and  the  rear  CAP  moved  forward. 
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(2)  Close  Air  Support.  The  CAS  division  attacked  tanks  (T-72s)  using  PGMs.  There 
was  a  division  a  rendezvous  following  take-off,  then  refueling  with  the  tanker  before 
proceeding  with  the  attack. 

(3)  Combined  Strike.  The  Combined  Strike  involved  three  sections  of  planes  participat¬ 
ing  in  a  coordinated  strike.  The  first  section  is  a  MiG-Sweep  (against  MiG-29s),  fol¬ 
lowed  by  a  SEAD  mission  (against  SA-9s)  and  the  final  one  a  strategic  attack  against 
a  bridge. 

(4)  FWA  Summary  of  Interoperability.  All  IFOR  missions  were  successfully  completed. 
The  damage  models  for  entities  need  to  be  updated  for  the  new  weapons  systems  that 
are  becoming  available.  Many  of  the  entities  attacked  by  IFOR  do  not  react  realisti¬ 
cally  to  air-to-ground  weapons  (specific  examples  include  T-72  and  T-80  tanks  and 
SA-9s).  There  also  has  to  be  a  general  process  within  the  overall  ModSAF  develop¬ 
ment  so  that  as  new  weapons  become  available,  all  ModSAF  entities  have  appropri¬ 
ate  damage  models.  The  IFOR  or  E-2C  did  see  other  forces,  and  on  the  first  day  was 
overwhelmed  with  ground  forces.  This  problem  was  fixed  so  that  by  the  second  day, 
the  E-2C  only  saw  air  vehicles  and  was  not  overwhelmed.  Unfortunately,  there  were 
many  unexpected  interactions  that  disrupted  the  IFOR  missions.  Red  aircraft 
(SU-25s)  attacking  the  fleet  caused  the  IFOR  CAS  missions  to  abandon  their  mis¬ 
sions  and  defend  the  fleet.  These  aircraft  were  generated  at  WISSARD.  A  Red  ship 
shot  down  some  of  the  IFOR  fighters  and  an  SA-2  site  near  one  of  the  bombing  tar¬ 
gets  distracting  the  IFOR  SEAD  mission  from  their  original  target  (although  they  did 
attack  the  SA-2  site  correctly).  It  is  unknown  if  the  source  was  the  Red  ship  or  the 
SA-2  site. 

b.  RWA.  The  overall  RWA  scenario  for  ED-1  involved  Red  ModSAF  ground  forces  (T-72 
tanks  and  ZSU23-4M  vehicles)  retreating  southeast  down  the  road,  being  attacked  at 
various  points  by  Blue  IFOR  RWA  (AH-64  Apaches).  There  was  no  intent  by  EFOR  to 
evaluate  the  behavior  of  OPFOR  units.  Five  vignettes  were  scheduled  varying  in  length 
from  about  20  minutes  to  about  50  minutes.  The  entities  for  these  scenarios  (including  the 
.  OPFOR  entities)  were  all  generated  during  ED-1  at  the  WISSARD  laboratory.  The  sce¬ 
nario  vignettes  are  provided  below,  followed  by  the  RWA  summary. 

(1)  Vignette  1.  This  included  a  Blue  team  of  two  RWA  scouts  and  a  Red  platoon  of 
tanks.  The  RWA  scout  team  flies  from  the  FARP  to  an  observation  point  in  combat 
spread  formation.  They  spot  the  tanks,  and  after  a  brief  first  volley  of  missiles  they 
fly  back  to  the  FARP. 

(2)  Vignette  2.  This  included  a  Blue  company  of  two  RWA  teams  (one  of  three  attack, 
and  one  of  two  attack)  and  a  Red  platoon  of  three  tanks  and  a  platoon  of  ZSU23-4M. 
The  RWA  company  flies  to  the  battle  position  in  staggered  trail  formation.  The  two 
teams  take  up  firing  positions  on  two  sides  of  a  hill.  After  a  5-  to  10-minute  engage¬ 
ment,  the  company  flies  back  to  the  FARP. 

(3)  Vignette  3.  Vignette  3  involved  a  Blue  company  of  two  RWA  teams  (one  of  one 
scout  and  two  attack,  and  one  of  one  attack)  and  a  Red  platoon  of  three  tanks  and  a 
platoon  of  ZSU23-4M.  The  RWA  company  flies  towards  the  battle  position  in  trail 
formation.  At  the  release  point,  the  attack  helicopters  hold,  while  the  scout  pulls  out 
ahead  to  the  battle  position.  If  the  scout  observes  enemy  vehicles,  it  retrieves  the 
attack  RWA  and  brings  them  forward  to  the  battle  position.  It  then  relays  their  firing 
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positions  and  target  priorities.  After  a  5-  to  10-minute  engagement,  the  company 
flies  back  to  the  FARP. 

(4)  Vignette  4.  Vignette  4  involved  a  Blue  team  of  three  attack  RWA  and  a  Red  platoon 
of  three  tanks  and  one  ZSU23-4M.  The  team  flies  towards  the  battle  position  in  trail 
formation.  After  a  5-  to  10-minute  engagement,  the  team  flies  back  to  the  FARP. 

(5)  Vignette  5.  The  final  vignette  involved  a  Blue  team  of  three  RWA  (two  attack  and 
one  scout)  and  a  Red  platoon  of  three  tanks  and  one  ZSU23-4M.  The  team  flies 
towards  the  battle  position  in  trail  formation.  The  scout  breaks  off  at  the  release  point 
and  takes  up  a  flank  security  position  at  one  battle  position.  The  attack  helicopters 
take  up  their  positions  at  a  second  battle  position.  After  a  5-to  10-minute  engagement 
by  the  attack  helicopters,  the  team  re-forms  and  flies  back  to  the  FARP. 

(6)  RWA  summary  of  interoperability.  Successfully  completed  all  five  vignettes,  attack¬ 
ing  the  OPFOR  that  was  available.  Received  some  surprises  from  unexpected  inter¬ 
actions  with  other  forces.  The  most  significant  was  discovering  that  the  RWA  vision 
“model”  could  be  overwhelmed  by  a  large  ground  force,  which  was  discovered  by 
flying  near  a  Blue  Marine  Expeditionary  Force  (generated  by  MCSF).  The  helicop¬ 
ters  got  bogged  down  in  “visual”  processing,  and  failed  to  pay  sufficient  attention  to 
their  flying  (and  thus,  would  sometimes  crash  and  bum).  Short-term  fixes  were 
developed  in  time  for  the  final  day  of  ED-1;  however,  for  the  longer  term,  a  better 
perceptual  attention  capability  is  needed.  There  was  inadequate  ModSAF  weapon 
and  behavior  models  that  made  interoperability  less  realistic  than  it  might  otherwise 
have  been.  For  example,  Hellfire  hit  and  kill  probabilities  were  generally  way  off 
from  what  would  have  been  realistic,  and  did  not  vary  appropriately  as  a  function  of 
the  target  vehicle.  Hellfire  missiles  failed  to  track  appropriately  on  their  targets  as  the 
computational  load  got  higher.  Together  these  phenomena  led  the  helicopters  to  use 
many  more  missiles  than  would  have  been  realistic.  Changes  were  made  to  the  tables 
locally  at  various  times  during  ED-1  to  make  them  more  realistic  (based  on  SME  and 
VV&A  advice),  but  this  left  them  still  quite  ad  hoc.  In  addition,  some  OPFOR 
behavior  models  were  unrealistic.  For  example,  ModSAF  ZSUs  can  acquire  and  fire 
almost  immediately,  rather  than  requiring  the  ~  10  seconds  they  would  if  controlled 
by  people  in  the  real  world.  This  changes  the  effectiveness  of  such  Blue  tactics  as 
popup  attacks.  Also,  behaviors  did  not  exist  to  keep  the  OPFOR  ZSUs  and  tanks 
together  and  coordinated,  so,  for  example,  the  two  groups  often  inappropriately  split 
up  with  the  ZSUs  stopping  and  scrambling  because  they  saw  some  Blue  vehicle, 
while  the  tanks  would  blithely  continue  on  their  way.  The  RWA  would  sometimes 
fire  at  vehicles  that  already  show  up  as  dead  on  the  PVD.  This  may  be  an  issue  of 
time  lag  in  updating  the  entity-state  model  between  the  machines  generating  the 
OPFOR  and  the  RWA,  or  may  result  from  the  inappropriate  “gun-barrel-tracking” 
logic  used  in  ModSAF  hellfire  missiles.  It  was  unrealistic  for  the  RWA  to  not  be 
able  to  reposition  themselves  if  the  enemy  was  not  where  they  were  expected  to  be. 
However,  this  is  a  capability  that  was  planned  for  post  ED-1.  Improved  logic  is 
required  for  dealing  with  situations  in  which  enemy  vehicles  are  perceived  that  are 
not  a  threat  (and  possibly  other  not  yet  observed  vehicles  that  are  a  threat),  for  deal¬ 
ing  with  enemy  that  are  out  of  range,  and  for  deciding  which  entities  within  a  single 
targeting-priority  class  should  be  targeted  first.  At  one  point,  a  pair  of  Air  Force 

A- 10s  strayed  into  the  IFOR  area  and  were  shot  down  by  one  of  the  OPFOR  ZSUs. 
This  altered  the  position  of  the  OPFOR  when  it  came  time  to  engage  with  the  IFOR 
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AH-64s.  Other  unexpected  interactions  generally  involved  the  presence  of  Blue 
ground  or  RWA  forces  (from  MCSF).  They  were  successfully  ignored  by  the  IFOR 
RWA,  but  would  frequently  cause  the  OPFOR  to  slow  down  or  to  scramble  prema¬ 
turely,  thus,  altering  the  expected  timing  and  location  of  the  engagement. 

c.  Joint  Scenario.  In  addition  to  these  RWA  and  FWA  results,  on  October  20,  IFOR  dynami¬ 
cally  created  a  joint  scenario  combining  both  RWA  and  FWA  (this  was  a  synchronized 
rather  than  a  coordinated  joint  mission).  It  used  an  existing  RWA  scenario,  but  required 
creation  of  a  new  FWA  scenario  from  scratch.  After  approximately  90  minutes  prepara¬ 
tion,  IFOR  was  able  to  successfully  run  the  scenario.  The  scenario  involved  Blue  RWA 
(AH-64s)  and  FWA  (F-14s)  on  attack  missions.  Blue  FWA  (F-18s)  on  a  SEAD  mission, 
and  Red  ground  forces  (ZSUs  and  T-80s)  that  were  fleeing.  During  the  engagement,  the 
F-18s  took  out  one  ZSU,  with  the  AH-64s  mopping  up  the  rest  of  the  column.  The  F-14s 
dropped  dumb  bombs  that  fell  near,  but  did  not  damage  the  tanks. 

3.  Army  SF.  No  problems  noted  with  interoperating  ModSAFs  between  services.  There  was 
good-to-excellent  interaction,  but  not  fully  joint:  Navy/USMC;  Army/AF;  and  IFOR.  Coor¬ 
dination  with  designated  Air  units  for  CAS  was  excellent. 

3.2.3.2  Navy.  There  were  no  IT  or  ED-1  test  objectives  that  specifically  addressed  SFI,  but  there 
were  many  successful  Navy  SF  interactions  as  a  result  of  DIS  compatibility  with  other  service  syn¬ 
thetic  forces  observed  during  ED-1.  NSF  successfully  interoperated  with  Army  SF,  CFOR,  Navy  SF, 
MCSF,  and  AFSF  in  a  realistic  battle  scenario  populated  by  geographically  dispersed  sites  (NRaD, 
EDA,  WISSARD,  and  JTASC).  There  were  successful  engagements  between  NSF  ships  and  AFSF 
aircraft,  and  between  NSF  ships  and  MCSF  tanks.  There  was  an  attempt  to  demonstrate  a  MCSF 
embark  onto  Navy  SF  landing  craft  and  then  debark  onto  shore,  which  was  unsuccessful  during 
ED-1.  There  was  an  unsuccessful  attempt  to  demonstrate  CCSIL  message  communications  between 
an  SH-60  flown  by  Navy  AirSAF  on  an  OTH  surface-to-surface  engagement  mission,  and  a  NSF 
Aegis  Cruiser.  Navy  SF  successfully  interfaced  with  the  OS  provided  by  NAWC-AD,  but  there  were 
problems  with  the  OS  flyout  of  some  missiles. 

3.2.3.3  Marine  Corps.  Navy  SF  required  MCSF  LAV s  and  HMMWVs  to  “debark”  the  Navy  enti¬ 
ties.  Unfortunately,  MCSF  vignette  #1  was  almost  completed  when  Navy  SF  LCACs  and  LCUs 
came  ashore.  MCSF  accommodated  Navy  SF  by  “debarking”  MCSF  entities  without  any  specific 
mission  to  perform.  The  CAS  coordination  was  conducted  via  telephone,  WISSARD  provided  AV8s 
as  well  as  AH  Is  to  help  support  the  MCSF  MTC  mission.  Both  AV8s  and  AH  Is  provided  CAS  and 
Red  Close  Air  Support  (RCAS)  effectively  against  the  enemy  Russian  Armored  Personnel  Carrier 
(BMPs),  but  were  not  effective  against  dismounted  infantry  (Tube  Launched,  Optically  Tracked, 
Wireguided  Missile  Weapon  System,  TOW,  would  destroy  BMPs  but  would  not  destroy  dismounted 
infantryman  standing  right  next  to  the  vehicle).  In  some  instances,  the  AV8s  would  not  fire  on  the 
BMPs  when  called  to  provide  CAS.  At  NRaD,  MCSF  rifle  platoon,  60-mm  mortar  squad,  M240 
machine  gun  squad  embarked  onto  CH53s  and  CH46s  that  were  generated  from  WISSARD.  Once 
the  embarked  entities  reached  the  debarking  point,  the  rifle  platoon,  60-nim  mortar  squad  and  M240 
machine  gun  squad  debarked  successfully. 

3.2.3.4  Air  Force.  There  were  only  two  interactions  evaluated  between  SF  and  SE.  The  first  was 
between  the  aircraft  and  OPFOR  ground  targets.  As  previously  noted  in  paragraph  3.2.2.4,  the  air¬ 
craft  observed  and  identified  OPFOR  entities  as  threats.  Problems  relating  to  acquisition,  threat 
assessment,  and  target  priority  were  due  to  AFSF  behaviors  and/or  models.  However,  problems  with 
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OPFOR  damage  as  a  result  of  hits  by  Mavericks  is  a  problem  with  OPFOR  damage  assessment.  The 
other  interaction  was  with  bombs  blowing  up  dynamic  bridges  provided  by  the  SE  and  causing  a  bar¬ 
rier  to  be  placed  on  the  bridge.  Although  the  AFSF  entity  could  not  see  the  bridge,  they  were  able  to 
bomb  a  set  of  coordinates.  If  the  detonation  PDU  was  within  the  proper  distance  from  the  bridge,  it 
was  seen  by  the  bridge,  the  bridge  blew  up,  and  the  barrier  was  placed  on  the  bridge. 
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4.  RECOMMENDATIONS 


Recommendations  for  each  technology  area  are  presented  separately. 

4.1  ARMY 

The  Army  SF  recommendations  are  presented  for  CFOR,  then  for  IFOR. 

4.1 .1  Command  Forces  Recommendations 

Recommendations  for  the  CFOR  program  are  for  CFOR  development  to  expand  CFOR  into  other 
service  areas  and  additional  mission  areas.  Focus  should  be  on  providing  interaction  with  other  syn¬ 
thetic  forces  and  combined  arms  operations.  Additionally,  more  focus  should  be  applied  to  the 
integration  of  CEs  with  the  environment.  This  includes  dynamic  terrain,  weather,  and  phenomenol¬ 
ogy  effects. 

4.1 .2  Intelligent  Forces  Recommendations 

For  some  of  the  scenarios,  there  should  be  more  control  of  unexpected  interactions  between  inde¬ 
pendent  demonstrations.  The  interactions  can  disrupt  the  planned  purpose  of  the  demonstration 
(even  if  the  interactions  are  realistic,  that  might  not  be  the  purpose  of  the  demonstrations).  This  is 
not  to  argue  against  unplanned  interactions  in  general  (intelligent  reaction  to  unplanned  interactions 
is  a  critical  capability),  but  in  a  testing  environment  where  specific  capabilities  are  to  be  demon¬ 
strated,  the  ability  to  avoid  disruptive  interactions  is  important.  For  example,  IFOR  experienced  dif¬ 
ficulty  demonstrating  the  ability  to  perform  CAS  missions  because  enemy  strikers  were  constantly 
attacking  the  fleet.  IFOR  ended  up  demonstrating  the  ability  to  break  off  a  CAS  mission,  perform  an 
intercept,  and  then  have  the  surviving  planes  return  to  the  CAS  mission.  This  made  it  more  difficult 
to  demonstrate  a  complete  division-level  CAS  mission.  It  might  make  sense  to  have  some  subpart  of 
the  demonstrations  where  the  unplanned  interactions  are  minimized,  with  later  parts  of  the  demon¬ 
strations  allowing  them.  Having  a  large  pool  of  machines  available  in  an  unclassified  facility  would 
greatly  simplify  our  participation  in  future  events  such  as  ED-1. 

4.1 .3  STRICOM  Recommendations 

The  following  recommendations  were  received  from  STRICOM  for  the  Army  SF. 

1 .  Aircraft  need  to  be  able  to  reconcile  enemy  (or  UNKNOWN)  vehicles  that  are  not  actual 
threats; 

2.  Stealth  needs  smoothing  algorithms  to  better  cope  with  high  maneuver  rates;  aircraft,  tanks, 
even  ships  jittered,  especially  in  turns  and  rapidly  changing  states; 

3.  Need  a  better  approach  to  tactical  communication  and  more  realistic  configuration;  this  would 
supply  time-tagged  recorded  message  for  analysis  and  will  be  required  to  evaluate  the  com¬ 
mander’s  behavior  in  various  situations; 

4.  Need  to  synchronize  time  to  all  workstations  and  tie  this  into  all  recording  and  data  logging. 
Each  terminal  had  different  time  showing; 

5.  Need  correlation  between  bandwidth/packet  sizes  and  entity  states  and  dynamics;  look  at 
improved  tools  to  collect  dynamic  data; 
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6.  Ensure  that  expanded  force  structure  includes  very  detailed  replication  of  fire  support  coor¬ 
dination,  control,  and  planning  function  operators,  systems,  and  channels; 

7.  ModSAF  operators  need  special  training  as  new  entities  and  support/special  purpose  systems 
are  introduced  (Grizzley,  AVLB,  etc.). 

4.2  NAVY 

As  previously  stated,  this  was  the  first  implementation  of  Navy  Synthetic  Forces  in  a  major  dem¬ 
onstration.  While  many  problems  were  identified,  the  NSF  project  appears  to  be  on  a  successful  path 
towards  STOW  97.  This  was  demonstrated  during  ED-1,  where  Navy  SF  participation  required 
integration  with  various  other  simulations  at  varying  degrees  of  fidelity.  NSF  successfully  interoper¬ 
ated  with  other  service  synthetic  forces  (with  ASF,  CFOR,  NSF,  MCSF,  and  AFSF)  with  specialized 
servers  (Ordnance  Server)  using  a  core  technology  base  (ModSAF)  in  a  seamless  battle  space  popu¬ 
lated  by  geographically  dispersed  sites  (NRaD,  IDA,  WISSARD,  and  JTASC)  via  intelligent  commu¬ 
nication  networks. 

After  analyzing  the  data  that  were  collected  during  IT  and  ED-1,  it  is  clear  that  there  are  some 
Navy  SF  elements  that  need  improvement.  The  CG-59  was  the  only  hull  that  had  all  of  the  correct 
KA  parameters.  Where  there  were  unavailable  KA  parameters  for  the  other  four  hulls,  the  KA 
parameters  for  the  CG-59  were  used.  The  unavailable  parameters  for  the  four  hulls  include  fuel  con¬ 
sumption  rates,  acceleration  and  deceleration  rates,  cutout  arcs,  turning  diameter  distances,  radar 
mast  heights,  and  additional  parameters  for  the  AOE.  After  the  unavailable  KA  parameters  are  sup¬ 
plied  for  these  four  hulls,  UVT  and  IT  will  have  to  be  repeated.  NSF  communications  via  CFOR 
CCSIL  messages  was  unsuccessful  between  NRaD  and  WISSARD  during  ED-1.  This  will  have  to 
be  fixed  promptly,  as  it  is  an  important  step  towards  the  integration  of  intelligent  behavior  processes 
through  defined  entity  control  interfaces  (command  entities)  and  will  provide  realistic  behavioral 
representations  of  Navy  conuBand  and  control.  The  OS  provided  by  NAWC-AD  needs  improvement 
in  order  to  provide  high-fidelity  flyout  of  the  missiles  launched  by  NSF.  During  IT  and  ED-1  there 
were  many  recorded  problems  with  missile  flyouts  from  the  OS.  There  were  other  problems,  as  pre¬ 
viously  noted,  with  the  CIWS,  NSF  probability  of  hit  tables,  system  loading,  the  ModSAF  GUI,  and 
ModStealth  mapping/missing  model.  In  order  to  collect  radar  detection  range  information  in  future 
exercises,  it  would  be  beneficial  to  have  software  test  tools  that  allow  collection  of  specific  radar 
data.  The  problems  discovered  over  the  Test  Continuum  and  ED-1  will  provide  much  of  the  neces¬ 
sary  input  to  improving  the  NSF  system  and  help  strengthen  its  capabilities  as  it  progresses  down  the 
STOW  97  path. 

4.3  MARINE  CORPS 

As  the  ED-1  testing  was  performed,  it  was  clear  that  without  Marine  Corps  CFOR,  a  significant 
amount  of  user  interaction  was  required  with  the  MCSF  front-end.  In  addition,  interoperability 
issues  with  the  Navy  must  be  worked  out  before  testing  begins,  so  that  the  interoperability  test  can  be 
militarily  and  tactically  significant. 

4.4  AIR  FORCE 

A  more  detailed  and  formal  approach  to  data  collection  and  analysis  should  be  established  for 
future  AFSF  testing.  Additionally,  identification  of  testing  criteria  and  coordination  with  other  ser¬ 
vice  SFs  required  for  testing  should  be  included  in  this  planning.  Scenario  problems  were  noted 
when  CAS  aircraft  overflew  the  corridor  used  by  SOAR  entities.  AFSF  entities  saw  SOAR  OPFOR 
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as  threats,  and  attacked  them  when  they  were  acquired.  This  was  corrected  by  changing  the  routes 
that  the  CAS  aircraft  flew,  so  as  not  to  overfly  the  SOAR  area  of  operations.  This  would  have  been 
identified  earlier  if  the  entire  scenario  had  been  run  prior  to  17  October.  AFSF  would  like  to  run  sce¬ 
narios  prior  to  demonstrations  and  look  for  unintended  interactions  well  before  the  actual  demonstra¬ 
tions.  Also,  AFSF  would  need  to  be  aware  that  air  entities  travel  over  a  large  area  and  may  need  to 
overfly  areas  conducting  other  operations.  This  may  mean  unplanned  interactions  may  occur  and 
changes  to  the  scenario  may  not  be  feasible.  The  Air  Force  needs  to  coordinate  closer  with  the  Army 
when  planning  on  CAS.  Since  CAS  is  directly  tied  to  Army  operations,  the  Army  needs  to  identify 
the  times  they  expect  CAS  missions  to  either  be  on  station  or  to  be  available.  The  scenario  did  not 
have  CAS  until  well  into  the  Army  scenario,  and  it  appeared  the  best  time  for  CAS  was  earlier  in  the 
Army  scenario  rather  than  later.  Coordination  of  the  scenario  was  sometimes  confusing  when  the 
direction  was  for  everyone  to  run  a  specific  vignette  because  everyone  had  a  different  number  of 
vignettes  set  for  different  times.  Network  problems  experienced  by  AFSF  included  freeze-up  several 
times  during  the  scenario.  We  believe  this  was  due  to  the  way  version  2.0  handles  other  systems 
loading  new  scenarios.  Under  2.0,  when  any  network  system  loaded  a  new  scenario,  regardless  if 
they  were  using  the  same  PO  data  base,  the  AFSF  system  froze.  Under  1.5.1,  only  those  systems  on 
the  same  PO  data  base  would  freeze.  Since  multiple  PO  data  bases  were  used,  system  freeze  when 
someone  loads  a  new  scenario  was  not  experienced. 

4.5  SYNTHETIC  ENVIRONMENT 

What  was  demonstrated  was  the  initial  thrust  of  introducing  a  synthetic  environment  into  the  syn¬ 
thetic  battle  space.  SE  provides  a  firm  basis  with  which  other  weapon’s  models,  system  behaviors, 
and  other  major  components  introduced  into  the  synthetic  battle  space  can  be  used  to  measure  and 
modify  the  impact  of  sensor  platforms  and  performance  to  realistic  simulated  conditions.  The  syn¬ 
thetic  battle  space  is  no  longer  a  flat-earth  and  blue-sky  environment.  It  now  simulates  real-world 
conditions  with  real-world  impacts  on  mission  planning  and  the  execution  of  orders.  Much  work 
remains  ahead  to  further  identify,  build,  and  implement  behaviors,  and  introduce  sensor  performance 
models  that  consider  specific  environmental  conditions  that  can  now,  and  will  be  simulated.  Contin¬ 
ued  close  coordination  between  SE  and  SF  are  required  to  ensure  that  all  future  work  takes  full 
advantage  of  the  opportunities  ahead  to  fully  integrate  the  whole  synthetic  battle  space  into  a  man¬ 
ageable,  realistic  system  that  is  useful  for  mission  rehearsal,  mission  planning,  and  training. 
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5.  SUPPORTING  DATA 


5.1  SYNTHETIC  FORCES 

5.1.1  Army  Supporting  Data 

Supporting  data  for  Army  Synthetic  Forces  is  provided  in  Appendix  B.  This  appendix  also 
includes  the  IFOR  Problem  Change  Reports  generated  v/ith  the  status  of  each. 

5.1.2  Navy 

Supporting  data  for  Navy  Synthetic  Forces  is  provided  in  Appendix  C. 

5.1 .3  Marine  Corps 

Supporting  data  for  Marine  Corps  Synthetic  Forces  is  provided  in  Appendix  D. 

5.1.4  Air  Force 

Supporting  data  for  Air  Force  Synthetic  Forces  is  provided  in  Appendix  E. 

5.2  SYNTHETIC  ENVIRONMENT 

N/A 
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6.  REFERENCES 


6.1  GOVEBNMENT  DOCUMENTS* 

1 .  STOW97  Advanced  Concept  Technology  Demonstration  (ACTD)  Management  Plan  (Version 
7.0).  Washington,  DC:  U.S.  Atlantic  Command,  Advanced  Research  Projects  Agency,  Janu¬ 
ary  13,  1995. 

2.  Synthetic  Theater  of  War  (STOW)  Engineering  Demonstration  #1,  lA  Data  Collection  &  Anal¬ 
ysis  Plan.  San  Diego:  Naval  Conunand,  Control,  and  Ocean  Surveillance  Center  RDT&E 
Division  (Code  441),  November  15, 1995. 

3.  Synthetic  Theater  of  War  (STOW)  Engineering  Demonstration  #l  Test  Continuum  Test  Plan. 
San  Diego:  Naval  Command,  Control,  and  Ocean  Surveillance  Center  RDT&E  Division  (Code 
441),  October  12, 1995. 

4.  Synthetic  Theater  of  War  ( STOW)  System  Engineering  and  Integration  Plan  for  Engineering 
Demonstration  #i.  San  Diego:  Naval  Command,  Control,  and  Ocean  Surveillance  Center 
RDT&E  Division  (Code  441),  November  2, 1995. 

6.2  NON-GOVERNMENT  DOCUMENTS 

None. 


*For  further  information,  contact: 

Naval  Command,  Control  and  Ocean  Surveillance  Center  RDT&E  Division 
Attn:  T.  R.  Tieman 
Code  441 

San  Diego,  CA  92152-5001 
(619)  553-3562 
tieman@nosc.mil 
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7.  ACRONYMS 


AAI 

AAR 

AAR 

AAV 

AAW 

AAW 

ACTS 

ACTD 

AEW 

AFSF 

AI 

AirSF 

AirSAF 

AMRAAM 

ARL 

ARL:UT 

ASF 

AT 

ATF 

ATM 

ATDNet 

ATI 

AVLB 

AVMW 

AWS 


Advanced  Communication  Technology  Satellite  Asynchronous  Transfer  Mode  Inter¬ 
network 

Aerial  Refueling 
Air-to-Air  Refueling 
Amphibious  Assault  Vehicle 
Air-to-Air  Warfare 
Anti-air  Warfare 

Advanced  Communication  Technology  Satellite 

Advanced  Concept  Technology  Demonstration 

Airborne  Early  Warning 

Air  Force  Synthetic  Force 

Air  Interdiction 

Air  Synthetic  Forces 

Air  Semi-Automated  Forces 

Advanced  Medium  Range  Air-to-Air  Missile 

Applied  Research  Laboratories 

Applied  Research  Laboratories:  University  of  Texas 

Army  SF 

Anti-tank 

Amphibious  Task  Force 

Asynchronous  Transfer  Mode 

Advanced  Technology  Demonstration  Network 

Advanced  Telecommunications,  Incorporated 

Armored  Vehicle  Launched  Bridge 

Amphibious  Vehicle  Multi-Wheeled 

Aegis  Weapon  System 


Bn  Battalion 

BP  Battle  Plan 


C^  Command  and  Control 

C^I  Command,  Control,  Communications,  and  Intelligence 

CAP  Combat  Air  Patrol 

CAS  Close  Air  Support 

CCIP  Computer  Calculated  Impact  Point 

CCSIL  Command  and  Control  Simulation  Interface  Language 

CE  Command  Entity 

CFOR  Command  Forces 

CIG  Computer  Image  Generator 

CIWS  Close-In  Weapon  System 

CVBG  Carrier  Battle  Group 
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DARPA 

DSI 

DIS 

Defense  Advanced  Research  Projects  Agency 
Defense  Simulation  Internet 

Distributed  Interactive  Simulation 

ESC 

ED-1 

ED-IA 

Electronics  System  Command 

Engineering  Demonstration  #1 

Engineering  Demonstration- 1 A 

FAC 

FARP 

FLIR 

FLOT 

FO 

FSATS 

FWA 

Forward  Air  Controller 

Forward  Air  Refueling  Point 

Forward-looking  Infrared  Radar 

Forward  Line  of  Own  Troops 

Forward  Observer 

Fire  Support  Automated  Test  System 

Fixed  Wing  Aircraft 

GFCS 

GMB 

GPS 

GUI 

Gun  Fire  Control  System 

Ground  Maneuver  Box 

Global  Positioning  System 

Graphic  User  Interface 

HARM 

HP 

HRL 

HWS 

High-Speed  Anti-Radiation  Missile 

Hewlett-Packard 

Hughes  Research  Laboratories 

Harpoon  Weapon  System 

IC 

IDA 

IFOR 

IT 

Individual  Combatants 

Institute  for  Defense  Analyses 

Intelligent  Forces 

Integrated  Technologies 

JFACC 

JTASC 

JTF 

Joint  Forces  Air  Component  Commander 

Joint  Training  and  Analysis  Simulation  Center 

Joint  Task  Force 

KA 

Knowledge  Acquisition 

LADS 

LAR 

LAR-AT 

LAR-M 

LORAL  Advanced  Distributed  Simulation 

Light  Armored  Reconnaissance 

Light  Armored  Reconnaissance-Anti-tank 

Light  Armored  Reconnaissance-Mortar 

MAGTF 

MCG 

MCSF 

METT-T 

Marine  Air  Ground  Task  Force 

Mine  Countermeasures  Group 

Marine  Corps  Synthetic  Forces 

Mission,  Enemy,  Terrain,  Troops  available,  and  Time 
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MIB 

Management  Information  Base 

ModSAF 

Modular  Semi-Automated  Forces 

MTC 

Movement  to  Contact 

NAWC-AD 

Naval  Aviation  Warfare  Center-Aircraft  Division 

NCCOSC 

Naval  Command,  Control  and  Ocean  Surveillance  Center 

NOE 

Nap  of  the  Earth 

NRaD 

NCCOSC  RDT&E  Division 

NSF 

Navy  Synthetic  Forces 

NSSMS 

NATO  Sea  Sparrow  Missile  System 

NTC 

National  Training  Center 

NTP 

Network  Time  Protocol 

OPFOR  SAG 

Opposing  Forces  Surface  Action  Group 

OS 

Ordnance  Server 

OTH 

Over-the-horizon 

PCRs 

Problem  Change  Reports 

PDU 

Protocol  Data  Unit 

Pk 

Probability  of  Kill 

PO 

Persistent  Object 

PVD 

Plan  View  Display 

RCAS 

Red  Close  Air  Support 

RDT&E 

Research,  Development,  Test  and  Evaluation 

RITN 

Real-Time  Information  Transfer  and  Networking 

ROE 

Rules  of  Engagement 

RTB 

Return  to  Base 

RWA 

Rotary  Wing  Aircraft 

SAFSIMs 

Semi-Automated  Forces  Simulation 

SAFSTAs 

Semi-Automated  Forces  Station 

SAIC 

Science  Application  International  Corporation 

SE 

Synthetic  Environment 

SEAD 

Suppression  of  Enemy  Air  Defense 

SE&I 

System  Engineering  &  Integration 

SF 

Synthetic  Forces 

SFI 

Synthetic  Forces  Interoperability 

SGI 

Silicon  Graphics,  Inc. 

SIM 

Simulation 

SME 

Subject  Matter  Expert 

SSIT 

Subsystem  Integration  Test 

STOW 

Synthetic  Theater  of  War 

STOW  97 

Synthetic  Theater  of  War  97 

STRICOM 

Simulation,  Training  and  Instrumentation  Command 

STW 

Strike  Warfare 
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STXs  Situational  Test  Exercises 

TDB  Terrain  Data  Base 

TEC  Topographic  Engineering  Center 

TOW  Tube  Launched,  Optically  Tracked,  Wireguided  Missile  Weapon  System 

TWCS  Tomahawk  Weapon  Control  System 

USACOM  United  States  Atlantic  Command 
USMC  United  States  Marine  Corps 

UT  University  of  Texas 

UVT  Unit  Verification  Test 

vFTX  virtual  Field  Training  Exercise 

WISSARD  What  If  Simulation  System  for  Advanced  Research  and  Development 


APPENDIX  A 

PROBLEM  CHANGE  REPORT  (PCR)  LIST 

A-1  INTRODUCTION 

The  following  Problem  Change  Reports  (PCRs)  were  received  at  NRaD  during  the  SSITs  and 
EDs.  The  Navy  Synthetic  Forces  PCRs  are  followed  by  the  Marine  Corps  Synthetic  Forces. 

Requests  for  additional  information  should  be  addressed  to  the  Navy/Marine  Corps  SF  Configuration 
Manager,  Bemie  Higgins  (higgins@nosc.mil),  619-553-3566.  Although  there  were  problems  experi¬ 
enced,  there  were  no  PCRs  entered  into  the  NRaD  data  base  relating  to  the  following  synthetic 
forces: 

1.  Army  Synthetic  Forces; 

2.  Air  Force  Synthetic  Forces; 

3.  CFOR/IFOR; 

4.  Synthetic  Environment  (SE). 

A-2  NAVY  SYNTHETIC  FORCES 

Table  A-1  lists  the  Problem  Reports  for  Navy  Synthetic  Forces  (NSF). 


Table  A-1 .  Navy  Synthetic  Forces  PCRs. 


Number 

PRI. 

Title 

Status 

Action 

NSF-001 

2 

No  CCSIL  Between  NSF  &  Navy  Air 

Open 

B.  Edmonds, 

J.  Hines 

NSF-002 

5 

5-Inch  Not  Hitting  Targets 

Closed 

NSF-003 

2 

CIWS  Not  Engaging  Fast  Missiles 

Open 

J.  Hines 

NSF-004 

2 

CIWS  Engaging  Crossing  A/C  Out  of  Range 

Open 

J.  Hines 

NSF-005 

5 

Ships  Run  Aground 

Closed 

NSF-006 

5 

Link-11  36  Contacts 

Closed 

NSF-007 

3 

No  Comms  CVBG-to-ATF 

Open 

J.  Hines 

NSF-008 

2 

SM-2  No  Flyout 

Open 

A.  Wachter 

NSF-009 

5 

Movement  Anomalies 

Open 

K.  Ferguson 

NSF-010 

5 

Harpoon  Self  Launches 

Open 

K.  Ferguson 

NSF-011 

3 

GUI-Amphibious  Operational  Overlay 

Open 

SF  CCB 

NSF-012 

3 

GUI-Entities  Disappearing  &  Reappearing 

Open 

SF  CCB 

NSF-013 

3 

SQQ-89  Is  Not  Radar 

Open 

J.  Hines 
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Table  A-1 .  Navy  Synthetic  Forces  PCRs.  (Continued) 


Number 

PRI. 

Title 

Status 

Action 

NSF-014 

3 

AOE  CIWS  Won’t  Stop  Shooting 

Open 

J.  Hines 

NSF-015 

2 

Need  Larger  Smoke  Plume 

Open 

SF  CCB 

NSF-016 

2 

Sweep  Gear  Appears  as  Second  Ship 

Open 

SF  CCB 

NSF-017 

2 

Weapon  Detonations  Too  Small 

Open 

SF  CCB 

NSF-018 

2 

LCU  Appears  as  LCAC 

Open 

SF  CCB 

NSF-019 

2 

AOE,  LSD,  LPD,  &  Fishing  Boats  Appear  as 

LHDs 

Open 

SF  CCB 

NSF-020 

3 

CIWS  Rounds  Incorrect  &  They  Miss 

Open 

J.  Hines 

NSF-021 

2 

Fire  PDU  Error  Messages 

Open 

A.  Wachter 

NSF-022 

2 

Sea  Sparrow  No  Flyout 

Open 

A.  Wachter 

NSF-023 

5 

SM-2  No  Flyout 

Closed 

NSF-024 

2 

Harpoon  No  Flyout 

Open 

A.  Wachter 

NSF-025 

2 

Tomahawk  No  Flyout 

Open 

A.  Wachter 

NSF-026 

2 

Tomahawk  Lost  Enroute 

Open 

A.  Wachter 

NSF-027 

2 

Tomahawk  Misses  Target 

Open 

A.  Wachter 

NSF-028 

2 

Only  One  Tomahawk  in  Flight 

Open 

A.  Wachter 

NSF-029 

2 

Limited  Tomahawk  Target  Missions 

Open 

A.  Wachter 

A-3  MARINE  CORPS  SYNTHETIC  FORCES 

Table  A-2  lists  the  PCRs  Marine  Corps  Synthetic  Forces  (MCSF). 

Table  A-2.  Marine  Corps  Synthetic  Forces  PCRs. 


Number 

PRI. 

Title 

Status 

Action 

MCSF-001 

5 

USMC  Dl  entities  embark  but  do  not  debark 

Closed 

MCSF-002 

5 

Some  .rdr  files  cannot  be  found  at  load  time 

Closed 

MCSF-003 

1 

Core  dump.  On  follow  a  vehicle  by  LAV-AT,  On 
follow  a  vehicle  by  HMMWV-TOW 

Open 

J.  Yi 

MCSF-004 

5 

Constant  message  “MOVEMAP  ERROR= 
MOVEMAP_MAX_VERTICES  exceeded 
libgeometry’geo-cut-polygon  ()+MAX-VERTS 
exceeded” 

Closed 

MCSF-005 

4 

Placed  AAV  Pit.  in  column  or  stagger  column.  In 
both  cases,  created  “On  Line” 

Open 

C.  Hale 

MCSF-006 

1 

Core  Dump,  Assigned  Move  w/follow  leader,  task 
to  CAAT  team;  I  was  replacing  a  move  task 

Open 

C.  Hale 

MCSF-007 

5 

Receiving  error  message  “route  map  rules  not 
specified”  after  map  database  load 

Closed 

MCSF-008 

5 

USMC  AT  TOW  should  be  HMMWV  TOW 

Closed 
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Table  A-2.  Marine  Corps  Synthetic  Forces  PCRs.  (Continued) 


Number 

PRI. 

Title 

Status 

Action 

MCSF-009 

1 

Core  dump,  moved  Red  units  and  caused  core 
dump  running  on  Private  and  Sergeant 

Open 

C.  Hale 

MCSF-010 

1 

Embark/Debark  in  conjunction  w/NAVSAF  tows 
on  LCAC 

Open 

C.  Hale 

MCSF-011 

1 

Core  Dump  caused  by  entity  count/or  creation  of 
“Rifie  Platoon” 

Open 

B.  Hoff 

MCSF-012 

2 

Embark/Debark  in  helo  point  to  point  on  shore 

Open 

C.  Hale 

MCSF-013 

3 

PVD  displays  for  LAV  show  incorrect  vehicle 
markings,  and  LAV  turret  is  in  wrong  position 

Open 

C.  Hale 

MCSF-014 

5 

Embark/Debark  in  ship  to  shore  movement 

Closed 

MCSF-015 

5 

Emark/Debark  in  conjunction  w/NAVSAF  TWS  on 
LCAC 

Closed 

MCSF-016 

4 

Harrier  doesn’t  kill  Dl 

Open 

C.  Hale 

MCSF-017 

2 

“Mobility  Killed”  M1  still  moves 

Open 

J.  Yi 

MCSF-018 

3 

TOW  Team  moves  unexpectedly 

Closed 

MCSF-019 

5 

HMMWV  TOW  doesn’t  kill  red  Dl 

Open 

C.  Hale 

MCSF-020 

5 

AAVs  do  not  move  in  the  water 

Closed 

MCSF-021 

4 

AAVs  do  not  move  when  triggered  by  a  control 
measure 

Open 

J.  Yi 

MCSF-022 

3 

M1  Tank  platoon  reactions  to  enemy  fire  when 
enemy  not  detected  (UREACTIF) 

Open 

C.  Hale 

MCSF-023 

4 

M1  moves  to  assault  position  even  though  fire 
killed 

Open 

C.  Hale 

MCSF-024 

5 

Administrative  Error 

Closed 

MCSF-025 

5 

M1  moves  to  assault  position  even  though  fire 
killed 

Closed 

MCSF-026 

2 

HMMWV  TOW  rules  of  engagement  (ROE) 
incorrect 

Open 

J.  Yi 

MCSF-027 

2 

Default  values  are  incorrect 

Closed 

MCSF-028 

5 

CAAT  Team  Rules  of  Engagement  (ROE) 
incorrect 

Closed 

MCSF-029 

2 

Tank  platoon  has  Erratic  movement 

Closed 

MCSF-030 

3 

“Next”  button  in  text  editor  does  not  work 

Open 

C.  Hale 

MCSF-031 

3 

CAAT  Team  gets  stuck  in  the  water 

Open 

C.  Hale 

MCSF-032 

II 

CAAT  Team  assault  not  realistic 

Open 

J.  Yi 

MCSF-033 

II 

Vehicles  do  not  react  correctly  when  fired  upon 

Open 

J.  Yi 

MCSF-034 

5 

60-mm  Mortar  squad  has  movement  problem 
(ED-1  software) 

Closed 

MCSF-035 

2 

Movement  of  maneuver  element  to  assault 
position 

Open 

B.  Hoff 
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Table  A-2.  Marine  Corps  Synthetic  Forces  PCRs.  (Continued) 


Number 

PRI. 

Title 

Status 

Action 

MCSF-036 

5 

Company  embark  does  not  work 

Closed 

MCSF-037 

2 

Debark  causes  strange  behavior 

Open 

C.  Hale 

MCSF-038 

5 

Embark  does  not  function  correctly 

Closed 

MCSF-039 

2 

AAV  cannot  swim  using  a  tracked  wheel  hull 

Open 

C.  Hale 

MCSF-040 

2 

Tasker  does  not  include  all  munitions  &  LAV-25 
does  not  swim 

Open 

C.  Hale 

MCSF-041 

5 

General-purpose  attach  function  does  not  work. 

Closed 

MCSF-042 

1 

USMC  attack  causes  core  dump  or  hangs  the 
system 

Open 

B.  Hoff 

MCSF-043 

5 

Core  dump  caused  by  entity  count/or  creation  of 
“Rifle  Platoon” 

Closed 

MCSF-044 

1 

Option  Allow — env  causes  MCSF  core  dump 

Closed 

MCSF-045 

2 

M1  Platoon  does  not  kill  Red  Dl 

Open 

J.  Yi 

MCSF-046 

1 

Core  Dump,  ModSAF  BMP  Dl  platoon  causes 
core  dump 

Open 

J.  Yi 

MCSF-047 

“Move  Route”  incorrect  displayed  for  AAVs 

Open 

C.  Hale 

MCSF-048 

Need  to  integrate  SRI  mods  to  MCSF 

Closed 

MCSF-049 

Need  to  integrate  SRI  mods  to  MCSF 

Closed 

MCSF-050 

Suppressive  Fire  ROE  permissions  when 
SPAWNED  by  USMC  Assault 

Closed 

MCSF-051 

Both  40  mm  and  50  cal  firing  incorrectly. 

Open 

C.  Hale 
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APPENDIX  B 

ARMY  SYNTHETIC  FORCES  SUPPORTING  DATA 

The  following  information  is  provided  as  supporting  data  for  the  Army  Synthetic  Forces.  There 
was  no  supporting  data  for  CFOR.  STRICOM’s  Army  SF  input  is  contained  in  the  draft  Tactical 
Assessment  for  Engineering  Demonstration  No.  1  Report,  dated  8  December  1995. 

B-1  IFOR  CAPABILITIES 

The  following  supporting  data  relate  to  IFOR.  The  following  list  of  behavioral  capabilities 
was — ^as  of  23  August  1995  for  RWA  and  as  of  1  July  1995  for  FWA — expected  to  be  demonstrated 
in  ED-1.  Each  line  has  been  annotated  with  one  of  four  symbols,  signifying  whether: 

1.  The  behavioral  capability  was  successfully  demonstrated  in  ED-1  [+]. 

2.  The  behavioral  capability  was  ready  for  ED-1,  but  did  not  make  it  into  the  scenarios  that  were 
actually  demonstrated  [x]. 

3.  The  behavioral  capability  was  found,  through  further  KA,  to  actually  be  inappropriate,  and 
was  thus  omitted 

4.  The  behavioral  capability  was  appropriate  but  not  completely  implemented  by  ED-1,  and 
therefore  not  demonstrated  [-]. 

There  is  no  annotation  for  a  capability  that  was  demonstrated  but  that  did  not  work,  because  by  the 
final  day  of  ED-1,  all  of  the  demonstrated  capabilities  did  work  (modulo  had  some  continued  prob¬ 
lems  with  a  very  specific  RWA  situation  in  which  pop-ups  would  be  terminated  when  an  out-of¬ 
range  OPFOR  is  seen  rather  than  continuing  to  pop  up  higher  to  look  for  in-range  OPFOR).  The  one 
remaining  annotation,  [!],  used  in  the  list  below,  designates  behavioral  capabilities  that  we  did  not 
expect  to  be  able  to  demonstrate  in  ED-1,  but  we  were  able  to  successfully  demonstrate. 

B-1.1  RWA  Capabilities 
+'  1.  Flying 

+  1.1  Take  off  and  landing  from/to  FARP 

+  1.2  Team  (pair)  formations 

X  1.2.1  Combat  cruise 

+  1.2.2  Combat  spread 

!  Also  demonstrated  teams  of  three  in  addition  to  two 

+  1 .3  Higher  formations  (up  to  company) 

X  1.3.1  Wedge 

X  1.3.2  Line 

+  1.3.3  Trail 
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+  1 .3.4  Staggered  left/right 

X  1 .3.  Echelon  left/right 

!  Companies  of  varying  sizes 

!  Robustness  under  members  of  the  company  dying 

+  1 .4  Route  following 

+  1.4.1  Flying  to  waypoints 

+  1 .4.2  Holding  at  waypoints 

+  1. 4.2.1  Hovering 

+  1. 4.2.2  Landing 

+  1.5  Terrain  following 

+  1.5.1  Low  Level 

+  1 .5.2  Contour 

+  1 .5.3  Nap  of  the  Earth  (NOE) 

+  1.6  Movement  techniques 

+  1.6.1  Traveling 

+  2.  Communication  (within  company)  [must  be  included  to  perform  mission,  but 
not  yet  really  for  testing  (or  in  CCSIL).] 

+  3.  Use  of  battle  positions 

+  3.1  Individual  aircraft  maneuvering 

+  3.1.1  Masking 

+  3.1.2  Unmasking 

+  3.1.3  Remasking 

+  3.1.4  Shifting  position 

3.2  Attack  section  maneuvering 

3.2.1  Changing  battle  positions 

+  3.3  Breaking  contact 

^  3.3.1  By  section 
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+  3.3.2  Simultaneously 

+  4.  Move  from  a  battle  position  [just  basic  return  to  FARR  Not  really  fortesting.] 
+  5.  Attrit  Mission 

!  Armed  Reconnaissance  Mission 

+  5.1  Attack  Helicopter  (AH-64) 

+  5.1.1  Target  Prioritization 

+  5.1 .1 .1  Giving  preference  to  APA 

!  Giving  preference  to  tanks 

+  5.1.2  Laser  Designation 

+  5.1. 2.1  Self  designation 

5.1 .2.2  Remote  designation 

5.1. 2.3  Offset  lasering 

+  5.1.3  Hellfire  Missile  Employment 

+  5.1. 3.1  Lock  on  before  launch 

5.1. 3.2  Lock  on  after  launch 

+  5.1.4  Attack  techniques 

+.  5.1 .4.1  By  individual  aircraft 

^  5. 1.4.2  By  section 

5.1 .4.3  By  section  using  remote  and  autonomous  fires 

5.1. 4.4  Simultaneous 

+  5.2  Scout  Helicopter  (AH-64) 

+/-  5.2.1  Detecting  enemy  position  and  scope  (within  realm  of  what  is 

expected)  <ln  particular,  demonstrate  detection  of  enemy  position  but  had  not 
completely  implemented  detection  of  scope> 

+  5.2.2  Scouting  battle  positions 

+  5.2.3  Guiding  attack  helicopters  to  battle  positions 

+  5.2.3. 1.  In  person 
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X 


5.2.3.2  Via  radio 


+  5.2.4  Detecting  unexpected  enemy  presence  [partial] 

!  Ignoring  irrelevant  enemy  and  friendly  presence 

B-1.2  FWA 

FWA  is  separated  by  types  of  actions,  as  shown  below. 

1 .  Section  Flying 

+  1.1  Flying  in  a  variety  of  formations:  combat  spread,  trail,  fighting  wing 
+  1.2  Formation  maneuvering: 

+  1.3  Changing  formations  during  a  mission. 

+  1.4  Changing  lead  during  a  mission. 

+  1.5  Fly  coordinated  air-to-air  tactics. 

+  1.6  Radar  contracts 
+  1.7  Find  partner 

+  1.8  Get  into  formation:  catch  up,  shackle  turn 
+  1.9  Strip  and  join 
+  1.10  Communication  cadence 
+  1.11  Wingman  track  progress  of  mission 
+  1.12  Wingman  take  shots  of  opportunity 
+  1.13  Wingman  request  refueling 

+  1.14  Section  ground-attack  maneuvers:  90  to  10,  split,  trail. 

X  1.15  Abort  mission  and  return  home  if  lose  lead 

2.  Division  Flying 

+  2.1  Flying  in  a  variety  of  formations:  box,  trail,  offset  box,  line  abreast 
+  2.2  Formation  maneuvering:  turns,  trail  turns 
X  2.3  Changing  formations  during  a  mission. 

X  2.4  Changing  lead  during  a  mission. 

+  2.5  Find  partner 
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+  2.6  Get  into  formation:  catch  up,  shackle  turn 
+  2.7  Strip  and  join 

+  2.8  Wingmen  track  progress  of  mission 
+  2.9  Wingmen  take  shots  of  opportunity 
+  2.10  Wingmen  request  refueling 
3.  Air-to-air  intercepts 
+  3.1  Appropriate  maneuvering  for  BVR 
+  3.1 .1  Achieve  TA  and  LS 

+  3.1.2  Counter  turns 

+  3.1.3  Pursue  from  behind 

+  3.2  Appropriate  use  of  radar 
+  3.3  Employment  of  appropriate  missiles 
+  3.3.1  Radar-guided  -  not  fire  and  forget 

+  3.3.2  Radar-guided  -  fire  and  forget 

+  3.3.3  Infrared 

!  3.3.4  Used  Ordnance  Server 

+.  3.4  Support  radar-guided  when  necessary  -  fpole 
+  3.5  Pick  target  (and  sort) 

+  3.6  Situational  awareness  from  controller 
+  3.6.1  Receive  brash  in  broadcast  control 

3.6.2  Receive  brash  in  close  control 
+  3.6.2  Request  when  necessary  (bogey-dope) 

+  3.6.3  Discontinue  when  not  necessary  Gudy) 

+  3.7  Command  and  control  from  controller 

+  3.8  Determine  if  achieve  commit  criteria 

+  3.9  Maintain  memory  of  bandit  out  of  sensor  envelope 
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+  3.9.1  Can  use  prior  visual,  radar,  or  comm,  information. 

+  3.10  Search  for  lost  bandit 
+  3.10.1  Look  at  most  recent  position 

+  3.10.2  Adjust  radar  elevation  and  azimuth  to  search 

X  3.11  Blow  through 
+  3.12  Take  evasive  action 
+  3.12.1  Beam 

+  3.12.2  Change-piece-of-sky  when  bogey  in  beam 

+  3.13  Identify  contacts 
+  3.14  Interpret  bogey  behavior 

4.  Combat  Air  Patrol 
+  4.1  Fly  racetrack 

+  4.1.1  Fly  to  racetrack 

+  4.1.2  Fly  legs  of  racetrack 

+  4.2  Command  and  control  from  E-2C  controller 
+  4.2.1  Receive  bogey  information  (3.6) 

+.  4.3  Redirection  to  new  CAP  stations 
+  4.3.1  Based  on  CAP  station  priority 

+  4.4  Control  of  multiple  CAP  stations  by  controller 
+  4.5  Inflight  refueling  as  needed 
+  4.6  Air-to-air  intercepts  (3.) 

5.  Close  Air  Support 
+  5.1  Plan  mission 

+  5.1 .1  Compute  times  to  achieve  waypoints 

+  5.1 .2  Compute  bingo  and  joker  fuel  levels  for  waypoints 

+  5.1.3  Plan  target  attack  tactics  (altitude,  geometry,  entry,  delivery) 


B-6 


X  5.1.4  Replan  during  flight  if  mission  changes 
+  5.2  Route  flying 
+  5.2.1  Fly  to  control  points 

+  5.2.2  Contact  appropriate  controllers  on  appropriate  radios 

+  5.2.3  Request  permission,  circle  if  none  given 

+  5.2.4  Fly  at  appropriate  speeds  and  altitude 

+  5.3  Attack  maneuvering 

+  5.3.1  Communicate  with  FAC  (cleared  hot,  tally  ho) 

+  5.3.2  Fly  attack  profiles  (geometry,  entry,  delivery) 

+  5.3.3  Return  attack  if  necessary 

+  5.4  Communication  and  coordination  between  planes  and  controllers 
+  5.4.1  Accept  changes  to  controllers,  radios,  route,  mission,  target 

+  5.4.2  Authenticate 

X  5.6  Timed  attacks  on  targets  (±10  seconds) 

X  5.6.1  Adjusts  speed  during  transit 

X  5.6.2  Delays  at  contact  point  if  necessary 

+,  5.6.3  Fly  ASAP  missions 

+  5.7  Bombing 

+  5.7.1  Conventional  munitions  using  CCIP 

+  5.7.2  Precision  guided  munitions  (self  lasing) 

+  5.7.3  Visual  acquisition  of  targets  (tanks) 

X  5.7.4  Track  moving  targets 

5.7.5  Drop  “trains”  of  bombs 
+  5.8  On-call  missions 
+  5.9  Inflight  refueling 
+  5.9.1  Refuel  at  prescribed  waypoints 
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+  5.11  Controllers: 


+  5.11 .1  Support  all  necessary  communication  with  planes 

+  5.11.1.1  authentication 

+  5.11.1.2  permission  to  enter 

+  5.11.1.3  deconfliction 

+  5.11.1.4  bda 

X  5.11.2  Relay  change  of  mission  requests  between  controllers 
+  5.11.3  FAC(A) 

+  5.11.3.1  Fly  grid  search 

+  5.11.3.2  Circle  target 

!  5.11.3.3  Mark  target  with  smoke 

+6.  MiG-Sweep 
+  6.1  Plan  mission  (see  5.1) 

+  6.2  Route  flying  (see  5.2) 

+  6.3  Air-to-air  intercepts  (see  3) 

X  6.4  Blow-through  (see  3.11) 

+7.  Take  off  and  landing 
+  7.1  Land  at  homebase  at  end  of  mission 
+  7.2  Takeoff  at  beginning  of  mission 
4-  7.3  Wait  for  scramble 

!  7.4  Section  or  division  take  off  with  coordinated  form  up  at  rendezvous  point 
!  7.5  Section  or  division  take  off  with  running  rendezvous 

+8.  Strategic  Attack  (see  8) 

+  8.1  Plan  mission  (see  5.1) 

+  8.2  Route  flying  (see  5.2) 

+  8.3  Attack  maneuvering  (see  5.3) 
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+  8.4  Communication  and  coordination  between  planes  and  controllers  (see 
5.4) 

+  8.5  Timed  attacks  on  targets  (±10  seconds)  (see  5.6) 

+  8.6  Bombing  (see  5.7) 

+  8.7  Inflight  refueling  (see  5.9) 

+  8.8  Controllers  (see  5.11) 

!9.  SEAD(see8) 

!  9.1  Firing  High-Speed  Anti-Radiation  Missile  (HARM)  Missiles 

B-2  IFORPCRS 
B-2.1  FWA 

This  is  a  detailed  list  of  the  bugs/weaknesses/needed-enhancements  found  in  the  IFOR  PWA  code 
as  a  result  of  ED-1.  A  description  of  the  problem  is  followed  by  the  status  of  the  problem. 

1.  There  were  several  core  dumps.  We  did  not  know  the  causes  of  these  at  the  time.  FIXED. 

2.  The  E-2C  sees  ground  vehicles  and  all  Blue  vehicles.  Temporary  fix  was  to  make  it  so  that  the 
radar  sensor  did  not  pass  these  in.  FIXED. 

3.  The  E-2C  needs  to  switch  to  close-control  for  committed  fighters  so  that  they  do  not  get  all  of 
the  broadcast  messages.  Maybe  need  to  increase  time  (currently  60  sec)  between  control 
reports.  Added  close-control.  FIXED. 

4.  We  need  to  fix  the  interface  for  missiles  handled  by  the  OS.  Waiting  for  new  version  of  OS. 
DEFERRED. 

5.  Terminal  targeting  needs  to  be  improved  so  that  we  get  off  bomb  drops  better.  One  bug  was 
found  and  fixed  the  night  before  ED-1 .  A  new  method  for  terminal  targeting  was  imple¬ 
mented.  FIXED. 

6.  Targeting  of  moving  targets  is  a  problem.  Need  to  make  it  possible  for  Computer  Calculated 
Impact  Point  (CCIP)  to  be  set  to  a  target.  FIXED. 

7.  Should  not  use  waypoint  computer  once  CCIP  is  enabled.  FIXED. 

8.  IFOR  need  to  return  to  base  (RTB)  when  a  Combat  Air  Patrol  (CAP)  mission  runs  out  of  mis¬ 
siles  (or  just  gets  low).  FIXED. 

9.  Problem  targeting  the  SA-9s  when  there  was  an  SA-2  (we  didn’t  see  the  SA-9s,  or  at  least 
didn’t  target  them).  Could  not  duplicate  because  an  SA-2  could  not  be  created.  Still  a  mystery 
where  it  originated.  REMOVED. 

10.  The  HARMS  missed  when  there  was  a  heavy  load  on  the  machine.  Still  a  potential  problem. 
Need  to  use  OS  in  the  long  run.  DEFERRED. 

11.  Continuous  calls  for  partner  and  continual  selections  of  the  disregard-bogey-comm  info.  This 
was  one  of  two  to  three  bad  bugs.  FIXED. 
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12.  FPole  should  be  20  degrees,  not  40  degrees  (according  to  Mark  C.).  Misinterpreted  comments 
by  SME.  Not  a  problem.  It  was  changed  to  20  degrees  to  help  debug  the  OS,  but  should  stay 
at  40  degrees.  REMOVED. 

13.  Sometimes  an  intercept  was  committed  very  late.  Does  the  commit  operator  compete  with  fly- 
flight-plan  (or  something  like  this),  so  if  we  don’t  terminate  one  of  those  operators,  we  don’t 
get  the  intercept?  Could  not  duplicate.  Not  confirmed  as  a  bug.  REMOVED. 

14.  Skywalk-1  once  refueled  twice.  FIXED. 

15.  Need  E-2C  and  other  missions  to  call  “SCRAM  north/south/090/...”  if  one  section  is  firing 
near  another.  NOT  FIXED. 

16.  Also  need  “winchester”  for  meaning  out  of  missiles  (well,  probably  don’t  need  it,  but  it 
sounds  so  cool).  FIXED. 

17.  Need  to  check  the  code  for  when  section/division  members  are  lost.  Leia-1  SNCed  once. 
FIXED. 

18.  Got  a  loop  between  identify-by-call-sign  and  forget-bogey.  FIXED. 

19.  Wingman  incorrectly  calls  joker  after  takeoff  when  headed  for  tanker.  Should  either  say  noth¬ 
ing,  or  “requires  texaco.”  NOT  FIXED  YET. 

20.  Fighter  sections  say  clean  even  when  they  are  not  expected  to  see  bogey  (such  as  during 
refueling).  Should  not  respond  then.  NOT  FIXED  YET. 

21 .  When  bogey  is  headed  toward  plane,  plane  should  call  “nose  hot.”  NOT  FIXED  YET. 

22.  Once  fighters  have  bogeys,  they  will  take  over  the  cadence  of  communication  with  the  E-2. 
NOT  HXED  YET. 

23.  Everything  heard  on  the  Fleet  Air  Defense  (FAD)  radio  should  be  heard  by  the  wingman. 

NOT  FIXED  YET. 

B-2.2  RWA 

1.  Improve  RWA  flight  dynamics,  particularly  under  heavy  computational  load.  To  be  taken  care 
of  by  ESC  and  LADS? 

2.  Make  turns  smoother  and  more  computationally  efficient.  Slow  down  as  a  function  of  sharp¬ 
ness  of  turn  and  size  of  group  turning.  Look  at  adjusting  rate  of  turn.  Work  on  clean  and  coor¬ 
dinated  takeoffs.  Work  on  smooth  (non-swiveling)  slow  down.  Smooth  and  made  turns  more 
computationally  efficient.  Improved  takeoffs. 

3.  Look  into  flying  at  higher  speed  (120  or  even  140  kn)  in  low-level.  See  if  accelerating  more 
slowly  (either  through  intermediate  waypoints  or  altering  ModSAF’s  rate  of  change  in  accel¬ 
eration)  will  help.  Can  now  fly  up  to  110  kn  by  more  carefully  controlling  acceleration. 

4.  Get  more  realistic  OPFOR,  for  example  ZSUs  that  require  ~  10s  to  fire  from  time  of  first  visi¬ 
bility,  rather  than  ~0s  (and  that  will  stay  with  the  tanks  they  are  accompanying  rather  than 
abandoning  them).  To  be  taken  care  of  by  OPFOR  community? 

5.  Implement  remote  designation. 

6.  Figure  out  general  criteria  for  height  of  popup,  when  to  terminate  popup  before  reach  planned 
height  (based  on  general  threat  and  opportunity  criteria?),  and  when  to  leave  battle  position. 
Some  analysis  performed. 
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7.  While  flying,  set  terrain  lookahead  as  a  function  of  speed,  and  set  speed  (and  possibly  altitude) 
as  a  function  of  visibility. 

8.  Work  out  a  solution  for  RWA  visual  overload  problems.  In  early  stages  of  working  on  this. 

9.  Work  on  robustness  of  groups  when  entities  are  killed.  In  particular,  need  to  be  able  to  assume 
important  positions  such  as  commander  or  scout  when  such  die.  Part  of  planned  work  on  team 
behavior. 

10.  Work  on  general  criteria  for  returning  to  FARP,  including  when  damage  to  the  unit  necessitates 
this.  Performed  KA  on  criteria  for  returning  to  FARP. 

11.  Work  on  overall  efficiency,  but  particularly  when  turning  and  engaging.  Solved  one  major 
RWA  efficiency  problem. 

12.  Work  on  appropriate  response  to  reaching  Battle  Plan  (BP)  and  finding  enemy  to  be  out  of 
range.  This  may  include  moving  to  a  new  BP,  or  sending  a  scout  out  to  act  as  remote  designa¬ 
tor.  Significant  progress  was  made  in  the  context  of  CFOR  terrain  reasoning  work. 

13.  Add  remaining  company  and  team  formations,  including  some  more  flexible  and  less  predict¬ 
able  real-world  formations  (as  described  by  Captain  Don  Lassiter).  Added  significant  flexibil¬ 
ity  to  formation  flying. 

14.  Add  (or  get  someone  else  to  add)  RWA  countermeasures;  in  particular,  RWR  and  IR  jamming. 
RWR  should  provide  360-degree  information  about  direction,  distance,  and  identity  of  entities 
illuminating.  Needs  to  be  deferred  to  others. 

15.  Determine  why  RWA  are  firing  missiles  at  dead  vehicles.  Is  it  because  of  a  communication 
delay  when  Red  and  Blue  are  on  different  machines?  Is  it  because  of  waiting  for  the  “barrel” 
to  track  the  target  between  when  a  fire  missile  comm  is  given  by  the  agent,  and  when  the  mis¬ 
sile  is  actually  fired?  Whatever  the  reason,  this  needs  to  be  fixed. 

16.  Can  we  eliminate  (or  get  eliminated)  this  whole  issue  of  “barrel  tracking”  for  missiles  such  as 
hellfires,  and  get  hellfire  tracking  fixed  in  general?  Needs  to  be  deferred  to  others. 

17.  Terrain  understanding/reasoning  for  RWA  while  flying  (to  enable  selecting  new  battle,  firing, 
and  lasing  positions;  determine  waypoints  in  getting  to  newly  selected  positions;  and  allow 
flying  Nap  of  the  Earth  (NOE)  around  obstacles  rather  than  over  them).  Significant  progress 
in  the  context  of  CFOR  development. 

18.  Change  BP  when  appropriate.  Part  of  planned  CFOR  work. 

19.  Crossing  Forward  Line  of  Own  Troops  (FLOT). 

20.  Communicate  among  RWA  to  share  information,  as  appropriate,  with  other  vehicles  about 
what  has  been  determined  about  enemy  forces,  damage  to  friendlies,  etc.  General  reasoning 
and  models  of  other  RWA  could  be  used  here  to  determine  when  others  are  likely  to  have 
information,  but  likely  to  need  it.  More  explicit  knowledge-based  strategies  are  also  conceiv¬ 
able.  Progress  in  the  context  of  a  significantly  improved  model  of  team  behavior. 

21.  Make  sure  all  requisite  damage  tables  are  realistic.  Needs  to  be  deferred  to  others. 

22.  Work  on  target  prioritization  within  vehicle  class.  This  may  include  targeting  the  biggest  cur¬ 
rent  threat  within  a  class  and/or  further  partitioning  of  targets  (e.g.,  left-to-right)  across  RWA. 
Part  of  planned  work  on  perception  and  attention. 
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23.  Ferretting  out  vehicles  hidden  (in  terrain,  trees,  etc.)  and  attacking  them.  Part  of  planned  work 
on  perception  and  attention. 

24.  Alter.  RWA  vision  to  correspond  to  appropriate  angular  and  distance  limitations.  If  necessary, 
take  into  consideration  availability  of  TV  at  two  levels  of  magnification.  At  night,  will  need  to 
take  forward-looking  infrared  radar  (FLIR)  and  goggles  into  consideration  as  well.  Needs  to 
be  deferred  to  others. 
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APPENDIX  C 

NAVY  SYNTHETIC  FORCES  SUPPORTING  DATA 


The  following  information  is  provided  as  supporting  data  for  the  Navy  Synthetic  Forces,  provided 
as  analysis  items. 

C-1 .  ENGINEERING  -  BASIC  HULL 

DATA  REQUIRED:  Appearance  and  stability  of  testable  ship  icon  on  two-dimensional  display, 
and  verification  of  hull  width,  length,  height,  and  mass.  Battle  damage  assessment  is  also  included 
under  Basic  Hull  with  number,  type,  size,  and  location  of  weapons  and  status  of  engineering,  opera¬ 
tions,  and  weapons  systems  and  sensors  after  weapons  impact,  including  whether  impact  caused  cat¬ 
astrophic  or  noncatastrophic  damage. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  At  the  start  of  each  day  of  ED-1,  a  full-force  laydown,  consisting  of  approximately 
19  Navy  SF  Build  2  ships,  was  created.  Approximately  12  additional  hulls  were  also  created  to 
enhance  the  scenario  and  to  populate  the  Amphibious  Task  Force  (ATF)  and  the  Mine  Countermea¬ 
sures  Group  (MCG).  These  additional  hulls  were  not  testable  since  they  were  not  part  of  Build  2. 
The  DD-963  and  DDG-51  hulls  were  subjected  to  hits  from  underwater  mines,  SM2  missiles,  har¬ 
poon  missiles,  and  5-inch  shells.  Both  hulls  displayed  the  correct  catastrophic  damage  level,  50%, 
when  hit  with  one  large  weapon  (mine  or  SM-2),  and  100%  when  hit  by  two  large  weapons.  Hulls 
with  50%  catastrophic  damage  changed  to  100%  when  hit  by  one  or  more  5-inch  shells.  Note  that 
this  is  the  current  implementation  of  damage  to  show  capability,  not  a  validated  damage  model. 

EVALUATION:  SATISFACTORY.  The  observed  entity  appearance  and  characteristics  of  all  test¬ 
able  hulls  were  consistent  with  the  appearance  and  characteristics  contained  in  Navy  SF  software 
requirements. 

C-2.  ENGINEERING  -  POWERPLANT 

DATA  REQUIRED:  Appearance  and  stability  of  testable  ship  icon  on  a  two-dimensional  display 
while  ship  is  underway  at  various  ordered  forward  speeds. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  each  individual  testable  ship  icon  could  not  be  observed  at  all  times.  Most 
all  of  the  testable  ships  moved  as  ordered  throughout  the  four  days  of  ED-1,  but  there  were  a  few 
observed  anomalies.  On  19  October,  a  DDG-51  would  not  accept  a  modify  task  order  to  decrease 
speed,  then  it  jumped  10  nm  south  of  its  original  location.  On  20  October,  a  DD-963  moving  north 
as  part  of  the  CVBG  jumped  on  top  of  a  DDG-51,  also  in  the  formation.  On  20  October,  a  DDG-51 
with  the  ATF  jumped  out  of  its  assigned  area,  FSA-5,  but  jumped  back  within  seconds.  There  were 
several  movement  anomalies  recorded  for  the  nontestable  ships  (MCMs,  LCACs  and  LCUs) 
throughout  ED-1. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  overall  appear¬ 
ance  and  stability  of  testable  ship  icons  while  underway  at  various  ordered  forward  speeds  were 
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consistent  with  the  appearance  and  characteristics  contained  in  Navy  SF  software  requirements,  with 
investigation  of  noted  anomalies. 

C-3.  ENGINEERING  -  FUEL  CONSUMPTION 

DATA  REQUIRED:  Amount  (default)  of  fuel  carried  by  testable  ship  (in  gallons)  when  ship  is 
newly  created.  Amount  of  fuel  carried  by  testable  ship  at  start  of  event,  at  end  of  event,  and  amount 
of  fuel  used.  Ordered  speed  and  duration  of  fuel  consumption  test. 

APPLICABLE  SHIP  CLASSES;  CG-59,  DDG-51,  DD-963,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  default  fuel 
loads  were  not  checked  when  the  testable  hulls  were  created,  and  fuel  consumption  rates  of  all  test¬ 
able  hulls  were  not  observed  during  ED-1.  Fuel  consumption  tests  were  performed  during  UVT  and 
IT. 

EVALUATION:  NOT  OBSERVED 

C-4.  OPERATIONS  -  MANEUVERING 

DATA  REQUIRED:  Appearance  and  stability  of  testable  ship  icon  on  a  two-dimensional  display 
while  ship  is  underway  at  various  ordered  forward  speeds,  when  ordered  to  accelerate  or  decelerate 
to  a  new  ordered  forward  speed,  when  ordered  to  a  course  and  speed  that  provides  a  specific  relative 
wind  (FOXCORPEN),  and  when  maneuvering  to  avoid  collision.  Appearance,  stability,  and  turn 
radius  of  testable  ship  icon  on  two-dimensional  display  for  given  speed  and  rudder  combinations. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  each  testable  ship  maneuver  could  not  be  observed  at  all  times.  Most  of 
the  testable  ships  moved  as  ordered  throughout  the  four  days  of  ED-1  but  there  were  a  few  observed 
anomalies  that  were  discussed  above  in  “Engineering  -  Powerplant.”  From  earlier  testing  it  is 
known  that  the  acceleration/deceleration  and  turning  characteristics  are  correct  only  for  the  CG-59. 
The  DDG-51,  DD-963,  CVN-68,  and  AOE-6  models  all  use  CG-59  values  due  to  unavailable  KA. 
Turning  radius  tests  were  performed  during  UVT  and  IT,  and  FOXCORPEN,  acceleration/decelera¬ 
tion,  and  collision  avoidance  tests  were  performed  during  UVT. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  maneuvers  were  consistent  with  the  characteristics  and  capabili¬ 
ties  contained  in  Navy  SF  software  requirements,  with  the  exception  that  acceleration/deceleration 
and  turning  rates  for  all  hulls  were  the  same  as  the  CG-59. 

C-5.  OPERATIONS  -  GPS 

DATA  REQUIRED;  Position  (latitude  and  longitude)  of  testable  hulls. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  At  the  start  of  each  day  of  ED-1,  a  full-force  laydown  consisting  of  approximately 
19  Navy  SF  Build  2  ships,  was  created.  Approximately  12  additional  hulls  were  also  created  to 
enhance  the  scenario  and  to  populate  the  Amphibious  Task  Force  (ATF)  and  Mine  Countermeasures 
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Group  (MCG).  These  additional  hulls  were  not  testable  since  they  were  not  part  of  Build  2.  Each 
ship  was  positioned  in  accordance  with  a  predesigned  template  giving  latitude  and  longitude  for  each 
one.  Throughout  the  four  days  of  ED-1  the  testable  ship  locations  on  the  map  were  accurate  to  the 
level  of  fiddity  of  the  map  display. 

EVALUATION;  SATISFACTORY.  The  observed  entity  appearance  and  characteristics  of  all  test¬ 
able  hulls’  GPS  were  consistent  with  the  appearance  and  characteristics  contained  in  Navy  SF  soft¬ 
ware  requirements. 

C-6.  OPERATIONS  -  VOICE  NETS 

DATA  REQUIRED:  Text  of  CCSIL  messages  transmitted.  Verification  that  CCSIL  messages 
were  received.  Changes  in  course  and/or  speed  of  testable  ships,  and  LAMPS  helicopter,  as  a  result 
of  CCSIL  messages. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  Transmission  of  CCSEL  messages  from  NRaD  to  WISSARD  was  attempted  11  times 
during  ED-1.  All  attempts  failed.  On  17  October,  six  attempts  were  made  to  attach  the  Test  Actor  to 
testable  ships,  three  times  to  CG-59,  twice  to  DDG-51,  and  once  to  CVN-68.  On  18  October,  a 
CCSIL  message  was  transmitted  from  DDG-51  at  NRaD,  but  the  back-end  at  WISSARD  receiving 
the  message  crashed.  On  19  October,  three  attempts  to  send  CCSIL  messages  from  the  CG-59  at 
NRaD  were  made.  WISSARD  did  not  receive  any  of  them.  On  20  October,  no  attempt  to  transmit  a 
CCSDL  message  from  NRaD  to  WISSARD  was  reported.  On  20  October,  LINK-1 1  was  tested 
between  the  CVBG  and  the  ATF,  but  did  not  work.  Note  that  on  19  October,  just  prior  to  start  of  the 
exercise  with  no  network  traffic,  CCSIL  messages  were  successfully  passed  between  Navy  SF  and 
Air  SF. 

EVALUATION:  UNSATISFACTORY.  Based  on  the  collective  visual  observations,  the  character¬ 
istics  and  capabilities  of  testable  ship  Voice  Nets  were  inconsistent  with  the  characteristics  and  capa¬ 
bilities  contained  in  Navy  SF  software  requirements. 

C-7.  WEAPONS  SYSTEMS  -  Mk  45  5-INCH  GUN 

DATA  REQUIRED:  Magazine  inventory  by  type  of  projectile  of  each  Mk  45  5-inch  gun  carried 
by  testable  ship,  if  ship  is  newly  created.  Magazine  inventory  by  type  of  projectile  at  start  of  event 
and  at  end  of  event.  Number  of  rounds  selected  to  be  fired  in  each  salvo.  Projectile  t5q)e,  rate  of  fire 
ordered,  gun  selection  (fwd,  aft),  and  target  fired  at  (direct  fire),  or  location  fired  at  (indirect  fire)  for 
each  engagement.  Time  to  fire  the  ordered  number  of  rounds  (rapid  fire,  slow  fire).  Cutout  arcs  and 
range-to-target  when  first  round  is  fired.  Visual  representation  of  hits  or  misses  on  two-dimensional 
display.  Results  of  impacts  on  target. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 

ANALYSIS:  Mk  45  gun  engagements  were  conducted  every  day  during  ED-1,  firing  several 
hundred  rounds.  When  fired  at  a  stationary  land  target  such  as  a  tank  (with  both  direct  and  indirect 
fire),  there  was  only  one  recorded  hit  during  all  of  ED-1.  Analysis  shows  that  the  Navy  SF  use  of 
Mods  AF  probability  of  hit  tables  needs  improvement.  Blue  versus  Red  ship  engagements  were  con¬ 
ducted  on  17  October  and  19  October,  with  hits  scored  in  both  engagements.  From  UVT  and  IT 
results,  it  is  known  that  default  ammunition  inventory  and  magazine  decrementation  work  properly 
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in  the  CG-59,  DDG-51,  and  DD-963  hulls.  Earlier  testing  also  showed  that  the  number  of  rounds 
selected,  projectile  type,  rate  of  fire  ordered  (rapid  or  slow),  and  which  gun  selected,  work  properly. 
Cutout  arcs,  and  range-to-target  when  first  round  is  fired  were  tested  during  UVT.  Note  that  during 
ED-1,  all  hulls  used  the  CG-59  cutout  arcs. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  Mk  45  5-inch  guns  were  consistent  with  the  characteristics  and 
capabilities  contained  in  Navy  SF  software  requirements,  with  the  noted  probability  of  a  hit  problem. 

C-8.  WEAPONS  SYSTEMS  -  Mk  34/86  GUN  FIRE  CONTROL  SYSTEM  (GFCS) 

DATA  REQUIRED:  Firing  order  (engage,  cease  fire),  projectile  type,  rate  of  fire,  number  of 
rounds  used,  which  gun  (fwd,  aft)  used,  and  target  fired  at  (direct  fire)  or  location  fired  at  (indirect 
fire)  for  each  engagement.  Time  to  fire  the  ordered  number  of  rounds  (rapid  fire,  slow  fire).  Visual 
representation  of  shell  impacts  on  two-dimensional  displays.  Results  of  shell  impacts  on  target. 

APPLICABLE  SHIP  CLASSES:  DDG-51,  CG-59  and  DD-963 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above  were  recorded.  Visual  representation  of  hits  or  misses  and  results  of 
impacts  on  targets  were  recorded  in  logs,  along  with  any  anomalies.  The  Mk  34/86  GFCS  was  used 
every  day  of  ED-1  to  control  Mk  45  gun  engagements.  Several  hundred  rounds  were  fired.  When 
fired  at  a  stationary  land  target  such  as  a  tank  (with  both  direct  and  indirect  fire),  there  was  only  one 
recorded  hit  during  all  of  ED-1.  Analysis  shows  that  the  Navy  SF  use  of  ModSAF  probability  of  hit 
tables  needs  improvement.  Blue  versus  Red  ship  engagements  were  conducted  on  17  October  and 
19  October,  with  hits  scored  in  both  engagements.  From  UVT  and  IT  results,  it  is  known  that  the 
firing  order,  number  of  rounds  selected,  projectile  type,  rate  of  fire  ordered  (rapid  or  slow),  and  gun 
selection,  work  properly  in  the  DDG-51,  CG-59,  and  DD-963  hulls.  The  one  exception  is  that  the 
Cease  Fire  order  had  not  been  implemented  prior  to  ED-1. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  Mk  34/86  GFCS  were  consistent  with  the  characteristics  and 
capabilities  contained  in  Navy  SF  software  requirements,  with  the  noted  Cease  Fire  exception. 

C-9.  WEAPONS  SYSTEMS  -  Mk  1 5  CIWS 

DATA  REQUIRED:  Status  of  system  (auto  or  manual)  and  gun  selection  (fwd,  aft  or  starboard, 
port).  Magazine  inventory  of  each  Mk  15  CIWS  gun  carried  by  testable  ship,  if  ship  is  newly 
created.  Magazine  inventory  at  start  of  event,  at  end  of  event,  and  number  of  rounds  used  during 
event.  Number  of  rounds  selected  to  be  fired  in  each  salvo  or  default  selection.  Time  delay  between 
target  detection  and  when  first  round  is  fired.  Cutout  arcs  and  range-to-target  when  first  round  is 
fired.  Visual  representation  of  hits  or  misses  on  two-dimensional  displays.  Results  of  impacts  on 
target. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above  were  recorded.  Visual  representation  of  hits  or  misses  and  results  of 
impacts  on  targets  was  recorded  in  logs,  along  with  any  anomalies.  Mk  15  CIWS  engagements  were 
conducted  every  day  during  ED-1,  firing  several  hundred  rounds.  On  17  October  and  20  October, 
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four  ships  (CG-59,  DDG-52,  DD-963  and  AOE-6)  each  destroyed  hostile  aircraft  with  their  Mk  15 
CIWS  in  automatic.  On  18  October,  the  DD-963  and  AOE-6  both  destroyed  a  hostile  aircraft  with 
their  Mk  15  CIWS  in  automatic.  On  19  October,  CVN-68  destroyed  two  hostile  aircraft  with  the  Mk 
15  CIWS  in  automatic.  However,  on  17  October,  the  AOE-6  Mk  15  CIWS  continued  to  fire  after 
shooting  down  two  hostile  aircraft.  Also,  on  17  October,  the  CG-59  Mk  15  CIWS  fired  six  rounds  at 
a  hostile  aircraft,  all  missing,  vice  the  default  of  100  rounds  that  should  have  been  used  if  the  system 
continued  to  miss.  On  18  October,  the  CG-59  Mk  15  CIWS  fired  at  a  crossing  target  when  it  should 
not  have.  This  occurred  because  there  is  no  range  rate  input  programmed  into  the  Mk  15  CIWS 
model.  It  was  also  observed  during  ED-1  that  the  Mk  15  CIWS  would  not  always  engage  high-speed 
targets.  This  was  probably  due  to  the  software  contact  sample  rate  being  too  low,  allowing  high¬ 
speed  missiles  to  slip  past  the  CIWS.  From  UVT  and  IT  results,  it  is  known  that  default  ammunition 
inventory  and  magazine  decrementation  work  properly  in  all  hulls.  Cutout  arcs  and  range-to-target 
when  first  round  is  fired  were  tested  during  UVT.  Note  that  during  ED-1,  all  hulls  used  the  CG-59 
cutout  arcs 

EVALUATION:  UNSATISFACTORY.  Based  on  the  collective  visual  observations,  the  character¬ 
istics  and  capabilities  of  testable  ship  Mk  15  CIWS  were  inconsistent  with  the  characteristics  and 
capabilities  contained  in  Navy  SF  software  requirements. 

C-1 0.  WEAPONS  SYSTEMS  -  Mk  7/8  AEGIS  WEAPON  SYSTEM  (AWS) 

DATA  REQUIRED:  Magazine  inventory  of  SM2  and  SM2  BLK4  missiles  carried  by  testable 
ship,  if  ship  is  newly  created.  Magazine  inventory  of  SM2  and  SM2  BLK4  missiles  carried  by  test¬ 
able  ship  at  start  of  event,  at  end  of  event,  and  number  of  missiles  used  during  event.  Number  of 
SM2  or  SM2  BLK4  missiles  selected  to  be  launched  in  each  event.  Time  delay  between  launch 
order,  actual  launch  of  first  missile,  and  between  missile  salvos  for  multiple  launches. 

APPLICABLE  SHIP  CLASSES:  CG-59  and  DDG-51 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above,  were  recorded.  There  were  some  66  SM2  missile  launches 
observed  and  recorded  during  ED-1.  All  launches  were  successful  in  that  there  were  no  anomalies 
observed  with  regard  to  magazine  inventory  decrementation.  When  a  CG-59  or  DDG-5 1  was 
ordered  to  launch  an  SM2,  it  did.  From  UVT  and  IT  results,  it  is  known  that  the  default  missile 
inventory  and  decrementation  work  properly  in  the  CG-59  and  DDG-51  hulls.  Earlier  testing  also 
showed  that  the  number  of  missiles  selected  and  the  time  delays  work  properly. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  Mk  7/8  AWS  were  consistent  with  the  characteristics  and  capa¬ 
bilities  contained  in  Navy  SF  software  requirements. 

C-1 1 .  WEAPONS  SYSTEMS  -  TWCS 

DATA  REQUIRED:  Magazine  inventory  of  Tomahawk  missiles  carried  by  testable  ship,  if  ship  is 
newly  created.  Magazine  inventory  of  Tomahawk  missiles  carried  by  testable  ship  at  start  of  event, 
at  end  of  event,  and  number  of  missiles  used  during  event.  Number  of  Tomahawk  missiles  selected 
to  be  launched  in  each  event.  Time  delay  between  launch  order,  actual  launch  of  first  missile,  and 
between  missile  salvos  for  multiple  launches. 
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APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 


ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above  was  recorded.  There  were  13  Tomahawk  missile  launches  observed 
and  recorded  during  ED-1.  All  launches  were  successful  in  that  there  were  no  anomalies  observed 
with  regard  to  magazine  inventory  decrementation.  When  a  CG-59,  DDG-51,  or  DD-963  was 
ordered  to  launch  a  TLAM,  it  did.  From  UVT  and  IT  results  it  is  known  that  default  missile  inven¬ 
tory,  and  decrementation  work  properly  in  the  CG-59,  DDG-51,  and  DD-963  hulls.  Earlier  testing 
also  showed  that  the  number  of  missiles  selected  and  the  time  delays  work  properly. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  TWCS  were  consistent  with  the  characteristics  and  capabilities 
contained  in  Navy  SF  software  requirements. 

C-1 2.  WEAPONS  SYSTEMS  -  HWS 

DATA  REQUIRED:  Magazine  inventory  of  Harpoon  missiles  carried  by  testable  ship,  if  ship  is 
newly  created.  Magazine  inventory  of  Harpoon  missiles  carried  by  testable  ship  at  start  of  event,  at 
end  of  event,  and  number  of  missiles  used  during  event.  Number  of  Harpoon  missiles  selected  to  be 
launched  in  each  event.  Time  delay  between  launch  order,  actual  launch  of  first  missile,  and  between 
missile  salvos  for  multiple  launches. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above  were  recorded.  There  were  some  47  Harpoon  missile  launches 
observed  and  recorded  during  ED-1.  All  launches  were  successful  in  that  there  were  no  anomalies 
observed  with  regard  to  magazine  inventory  decrementation.  When  a  CG-59,  DDG-51,  or  DD-963 
was  ordered  to  launch  a  Harpoon,  it  did.  From  UVT  and  IT  results,  it  is  known  that  default  missile 
inventory  and  decrementation  work  properly  in  the  CG-59,  DDG-51,  and  DD-963  hulls.  Earlier 
testing  also  showed  that  the  number  of  missiles  selected  and  the  time  delays  work  properly. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  HWS  were  consistent  with  the  characteristics  and  capabilities 
contained  in  Navy  SF  software  requirements. 

C-1 3.  WEAPONS  SYSTEMS  -  Mk  57  NSSMS 

DATA  REQUIRED:  Status  of  system  (auto  or  manual)  and  gun  selection  (fwd,  starboard  aft,  port 
aft).  Magazine  inventory  of  Sea  Sparrow  missiles  carried  by  testable  ship,  if  ship  is  newly  created. 
Magazine  inventory  of  Sea  Sparrow  missiles  carried  by  testable  ship  at  start  of  event,  at  end  of  event, 
and  number  of  missiles  used  during  event.  Number  of  Sea  Sparrow  missiles  selected  to  be  launched 
in  each  event,  or  default  selection.  Time  delay  between  launch  order,  actual  launch  of  first  missile, 
and  between  missile  salvos  for  multiple  launches.  Cutout  arcs  and  range-to-target  when  first  missile 
is  fired. 

APPLICABLE  SHIP  CLASSES:  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario,  not  all  of  the 
detailed  data  as  described  above  were  recorded.  There  were  some  104  Sea  Sparrow  missile  launches 
observed  and  recorded  during  ED-1.  All  launches  were  successful  in  that  there  were  no  anomalies 
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observed  with  regard  to  magazine  inventory  decrementation.  When  a  DD-963,  CVN-68,  or  AOE-6 
was  ordered  to  launch  a  Sea  Sparrow,  it  did.  From  UVT  and  IT  results,  it  is  known  that  default  mis¬ 
sile  inventory  and  decrementation  work  properly  in  the  DD-963,  CVN-68,  and  AOE-6  hulls.  Ear¬ 
lier  testing  also  showed  that  the  automatic  launch,  number  of  missiles  selected,  and  time  delays  work 
properly.  Cutout  arcs  and  range-to-target  when  first  round  is  fired  were  tested  during  UVT.  Note 
that  during  ED-1,  all  hulls  used  the  CG-59  cutout  arcs. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  testable  ship  Mk  57  NSSMS  were  consistent  with  the  characteristics  and  capa¬ 
bilities  contained  in  Navy  SF  software  requirements. 

C-1 4.  WEAPONS  SYSTEMS  -  HARPOON  MISSILE 

DATA  REQUIRED:  Selection  of  OS  for  each  launch,  using  the  Entity  Control  Interface. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 

ANALYSIS:  A  total  of  47  Harpoon  missile  launches  were  observed  and  recorded  during  ED-1. 

Of  those  47,  the  OS  was  successfully  selected  19  times  to  launch  Harpoon  missiles  at  targets.  Using 
the  OS,  8  out  of  19  flyouts  were  successful,  and  7  of  the  8  hit  targets.  There  were  nine  launches 
using  the  OS  that  resulted  in  no  flyouts,  and  two  launches  that  flew  out  in  the  opposite  direction  from 
what  was  ordered.  There  was  one  anomaly  where  it  was  believed  that  two  Harpoon  missiles  were 
launched  without  the  operator  manually  ordering  them.  This  has  never  been  repeated. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  testable  ship  Harpoon  Missile  were  consistent  with  the  characteristics  and 
capabilities  contained  in  Navy  SF  software  requirements.  The  evaluation  of  the  Harpoon  Missile  as 
SATISFACTORY  does  not  include  the  performance  of  the  OS.  The  only  Navy  SF  requirement  here 
is  the  capability  to  use  the  Entity  Control  Interface  to  launch  a  Harpoon  missile  at  a  designated  target 
using  the  OS. 

C-1 5.  WEAPONS  SYSTEMS  -  TOMAHAWK  MISSILE 

DATA  REQUIRED:  Selection  of  OS  for  each  launch,  using  the  Entity  Control  Interface. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 

ANALYSIS:  A  total  of  13  Tomahawk  missile  launches  were  observed  and  recorded  during  ED-1. 
The  OS  was  successfully  selected  all  13  times.  Of  these,  five  flyouts  were  evaluated  as  successful, 
with  no  direct  hits  on  the  target.  There  were  eight  launches  using  the  OS  that  resulted  in  no  flyouts. 
During  one  event  on  17  October,  two  Tomahawk  missiles  were  launched  from  a  DDG-51,  but  only 
one  flyout  was  observed,  which  stopped  short  of  the  target.  While  the  flyout  was  in  progress,  two 
more  Tomahawk  missiles  were  launched,  but  no  flyouts  were  observed.  Analysis  indicates  that  the 
OS  could  only  support  one  missile  at  a  time.  All  successful  flyouts  ended  with  missile  impact 
between  70  ft  and  7  nm  away  from  the  target.  There  was  one  anomaly  where  it  was  believed  a  Tom¬ 
ahawk  missile  was  launched  without  the  operator  manually  ordering  it.  This  was  never  repeated. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  testable  ship  Tomahawk  Missile  were  consistent  with  the  characteristics 
and  capabilities  contained  in  Navy  SF  software  requirements.  The  evaluation  of  the  Tomahawk 
missile  as  SATISFACTORY  does  not  include  the  performance  of  the  OS.  The  only  Navy  SF 
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requirement  here  is  the  capability  to  use  the  Entity  Control  Interface  to  launch  a  Tomahawk  missile 
at  a  designated  target  using  the  OS. 

C-1 6.  WEAPONS  SYSTEMS  -  SM2  MISSILE 

DATA  REQUIRED:  Selection  of  OS  for  each  launch,  using  the  Entity  Control  Interface. 

APPLICABLE  SHIP  CLASSES:  CG-59  and  DDG-51 

ANALYSIS:  A  total  of  66  SM2  missile  launches  were  observed  and  recorded  during  ED-1.  Of 
those  66,  the  OS  was  successfully  selected  56  times  to  launch  SM2  missiles  at  targets.  With  using 
the  OS,  38  flyouts  were  successful  and  35  of  the  38  hit  targets.  There  were  18  launches  using  the  OS 
that  resulted  in  no  flyouts. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  testable  ship  SM2  Missile  were  consistent  with  the  characteristics  and 
capabilities  contained  in  Navy  SF  software  requirements.  The  evaluation  of  the  SM2  missile  as 
SATISFACTORY  does  not  include  the  performance  of  the  OS.  The  only  Navy  SF  requirement  here 
is  the  capability  to  use  the  Entity  Control  Interface  to  launch  an  SM2  missile  at  a  designated  target 
using  the  OS. 

C-1 7.  WEAPONS  SYSTEMS  -  SEA  SPARROW  MISSILE 

DATA  REQUIRED:  Selection  of  OS  for  each  launch,  using  the  Entity  Control  Interface. 

APPLICABLE  SHIP  CLASSES:  DD-963,  CVN-68,  and  AOE-6 

ANALYSIS:  A  total  of  104  Sea  Sparrow  missile  launches  were  observed  and  recorded  during 
ED-1.  Of  those  104,  the  OS  was  successfully  selected  24  times  to  launch  Sea  Sparrow  missiles  at 
targets.  Using  the  OS,  no  flyouts  were  observed.  Analysis  indicates  that  the  OS  was  not  integrated 
to  the  point  that  it  could  support  Sea  Sparrow  missile  launches.  In  nearly  every  case  without  the  OS, 
where  a  Sea  Sparrow  missile  did  not  hit  an  air  target,  it  circled  the  launching  ship  until  running  out  of 
fuel,  or  it  was  destroyed  by  additional  Sea  Sparrow  missiles  automatically  launched  against  it. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  testable  ship  Sea  Sparrow  Missile  were  consistent  with  the  characteristics 
and  capabilities  contained  in  Navy  SF  software  requirements.  The  evaluation  of  the  Sea  Sparrow 
missile  as  SATISFACTORY  does  not  include  the  performance  of  the  OS.  The  only  Navy  SF  require¬ 
ment  here  is  the  capability  to  use  the  Entity  Control  Interface  to  launch  a  Sea  Sparrow  missile  at  a 
designated  target  using  the  OS. 

C-1 8.  SENSORS  -  AN/SPY-1  B/D 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  and  aspect,  for  all  tar¬ 
gets,  and  altitude  for  air  targets. 
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APPLICABLE  SHIP  CLASSES:  CG-59  and  DDG-51 


ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  was  not  recorded,  but  the  AN/ 
SPY-IB/D  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with  the 
CG-59  and  the  DDG-51.  The  AN/SPY-IB/D  radar  was  tested  extensively  during  UVT  and  IT.  All 
16  AN/SPY-IB/D  requirements  that  were  tested  during  UVT  passed  for  the  CG-59  and  DDG-51, 
though  “best-guess”  radar  mast  heights  were  used  for  the  DDG-51  until  exact  heights  are  available. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPY-IB/D  were  consistent  with  the  characteristics  and  capabilities 
contained  in  Navy  SF  software  requirements. 

C-19.  SENSORS -AN/SPS-49 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  aspect,  and  altitude  for 
air  targets.  Bearing  and  range  of  any  surface  targets  detected. 

APPLICABLE  SHIP  CLASSES:  CG-59  and  CVN-68 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-49  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with  the 
CG-59  and  the  CVN-68.  The  AN/SPS^9  radar  was  tested  extensively  during  UVT  and  IT.  All  15 
AN/SPS-49  requirements  that  were  tested  during  UVT  passed  for  the  CG-59.  It  was  not  tested 
again  for  the  CVN-68  since  the  same  parameters  were  used. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-49  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-20.  SENSORS -AN/SPS-55 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  and  aspect  for  surface 
targets.  Bearing  and  range  of  any  air  targets  detected. 

APPLICABLE  SHIP  CLASSES:  CG-59  and  DD-963 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-55  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with  the 
CG-59  and  the  DD-963.  The  AN/SPS-55  radar  was  tested  extensively  during  UVT  and  IT.  All  16 
AN/SPS-55  requirements  that  were  tested  during  UVT  passed  for  the  CG-59  and  DD-963  though 
“best-guess”  radar  mast  heights  were  used  for  the  DD-963  until  exact  heights  are  available. 
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EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-55  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-21.  SENSORS -AN/SPS-67 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  and  aspect  for  surface 
targets.  Bearing  and  range  of  any  air  targets  detected. 

APPLICABLE  SHIP  CLASSES:  DDG-51,  CVN-68,  and  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-67  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with  the 
DDG-51,  CVN-68,  and  AOE-6.  The  AN/SPS-67  radar  was  tested  extensively  during  UVT  and  IT. 
All  11  AN/SPS-67  requirements  that  were  tested  during  UVT  passed  for  the  DDG-51,  though  “best- 
guess”  radar  mast  heights  were  used  until  exact  heights  are  available.  It  was  not  tested  again  for  the 
CVN-68  or  AOE-6  since  the  same  parameters  were  used. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-67  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-22.  SENSORS  -  AN/SPS-40 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  aspect,  and  altitude  for 
air  targets.  Bearing  and  range  of  any  surface  targets  detected. 

APPLICABLE  SHIP  CLASSES:  DD-963 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-40  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with  the 
DD-963.  The  AN/SPS^O  radar  was  tested  extensively  during  UVT  and  IT.  All  12  AN/SPS^O 
requirements  that  were  tested  during  UVT  passed  for  the  DD-963,  though  “best-guess”  radar  mast 
heights  were  used  until  exact  heights  are  available. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-40  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-23.  SENSORS  -  AN/SPS-48E 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  aspect,  and  altitude  for 
air  targets.  Bearing  and  range  of  any  surface  targets  detected. 
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APPLICABLE  SHIP  CLASSES:  CVN-68 


ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-48E  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with 
CVN-68.  The  AN/SPS-48E  radar  was  tested  extensively  during  UVT  and  IT.  All  but  one  of  the  10 
AN/SPS-48E  requirements  that  were  tested  during  UVT  passed  for  the  CVN-68,  though  “best- 
guess”  radar  mast  heights  were  used  until  exact  heights  are  available.  The  one  failure  (TR  025)  had 
to  do  with  a  missing  requirement.  There  was  no  requirement  to  ignore  surface  contacts  even  though 
the  SPS-48E  is  an  air-search  radar. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-48E  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-24.  SENSORS -AN/SPS-64 

DATA  REQUIRED:  Radar  ranges  and  delay  between  when  the  contact  is  first  detected  and  when 
the  contact  track  data  are  fully  known.  Radar  status  (on  or  off),  off,  if  it  is  damaged.  Radar  model 
output  including:  target  entity  ID,  entity  type,  bearing,  range,  speed,  course,  and  aspect  for  surface 
targets.  Bearing  and  range  of  any  air  targets  detected. 

APPLICABLE  SHIP  CLASSES:  AOE-6 

ANALYSIS:  Because  of  time  constraints  imposed  by  a  continuous  ED-1  scenario  and  the  large 
size  of  the  demonstration,  the  detailed  data  as  described  above  were  not  recorded,  but  the  AN/ 
SPS-64  radar  was  turned  on  during  most  of  ED-1  in  order  to  detect  and  engage  hostiles  with 
AOE-6.  The  AN/SPS-64  radar  was  tested  extensively  during  UVT  and  IT.  All  11  AN/SPS-64 
requirements  that  were  tested  during  UVT  passed  for  the  AOE-6,  though  “best-guess”  radar  mast 
heights  were  used  until  exact  heights  are  available. 

EVALUATION:  SATISFACTORY.  Based  on  the  collective  visual  observations,  the  characteris¬ 
tics  and  capabilities  of  the  AN/SPS-64  were  consistent  with  the  characteristics  and  capabilities  con¬ 
tained  in  Navy  SF  software  requirements. 

C-25.  SENSORS  -  SH-60  LAMPS  Mk  III 

DATA  REQUIRED:  Appearance  and  stability  of  SH-60  icon  on  two-dimensional  display  during 
launch  and  recovery  from  testable  ship.  Initial  course  and  speed  of  LAMPS  helicopter  as  a  result  of 
CCSIL  messages,  and  changes  as  a  results  of  additional  CCSIL  messages. 

APPLICABLE  SHIP  CLASSES:  CG-59,  DDG-51,  and  DD-963 

ANALYSIS:  CCSIL  messages  needed  to  initiate  this  event  were  not  successfully  transmitted  from 
NRaD  to  WISSARD  during  ED-1 . 

EVALUATION:  UNSATISFACTORY. 
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APPENDIX  D 

MARINE  CORPS  SYNTHETIC  FORCES  SUPPORTING  DATA 


The  following  information  is  provided  as  supporting  data  for  the  Navy  Synthetic  Forces,  provided 
as  Analysis  Items. 

VIGNETTE  1:  CAMP  PENDLETON 

Item  Unit  Intel!.  Size:  Location  Activity  Type  of  Unit 

vTi  Red  Force  Enemy  Pit.  BMP  Dl  593807  Holding  BMP/DI 


Red  Force  Location  593807 
Expected  Result  Entity  created? 


SETUP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

vTi  Red  Force  Enemy  Pit.  BMP  Dl  603815  Holding  BMP/DI 


Red  Force  Location  603815 
Expected  Result  Entity  created? 


Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

VI  .4  Red  Force  Enemy  Pit.  of  Tanks  561865  Hold  Tank  Pit. 


Red  Force  Location  561 856  o/o  move  to  578846 
Expected  Result  Result  of  movement: 


D-1 


SETUP  , 

Item  Unit  intell.  Size:  Location  Activity  Type  of  Unit 

V1 .5  Blue  Force  Friendly  Co  Task  Force  Shipboard  Hold  MAGTF 

Movement  from  ship,  to  Bn  CP  @  610780; 
movement  from  ship  to  shore,  to  610780 
movement  from  ship  to  LZ,  to  61 0780 

Expected  Result  Result  of  movement: 

Result  of  embark/debark: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .7  V21  610780  Move  to  Contact  591813  Perform  Route  Recon. 


V21  -  H59:  move  to  the  LOD 
Expected  Result  Result  of  movement: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .8  All  Units  610780  Move  to  Contact  593813  Move  Tactically 


All  Units  -  H59:  Move  to  PL  Black 
Expected  Result  Result  to  movement: 


On  Order;  SET  UP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

VI  .9  Red  Force  Enemy  Platoon  593807  Holding  BMP  /  Dl 


Weapons  Free  to  Engage 

Expected  Result 


D-2 


Item  Unit  Location  Mission  Objective  Tasks 

V1.10  All  Units  605788  Move  to  Contact  593807  Move  Tactically 


All  other  Units  -  H59:  Hold  Fire  &  Halt 
Expected  Result  Result  of  Hold  Fire  &  Halt: 


Item  Unit  Location  Mission  Objective  Tasks 

V1.11  W46  605788  Move  to  Contact  593807  Perform  attack  by  fire 


W46  -  H59:  ACTION:  (  ):  (Engage  Enemy  at  593807) 

Expected  Result  Result  of  engagement: 


Item  Unit  Location  Mission  Objective  Tasks 

VI. 12  X72  605788  Move  to  Contact  602798  Occupy  TOW  Fire  Position 


X72  -  H59:  ACTION  (  ):  (set  up  a  firing  position  at  602798  &  Engage) 
Expected  Result  Result  of  occupy  position: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .14  W46  605788  Move  to  Contact  593808  Conduct  Fire  and  Movement 


W46  -  H59:  Secure  Enemy  Firing  Position 
Expected  Result  Result  of  Fire  and  Movement: 


Item  Unit  Location  Mission  Objective  Tasks 

VI. 15  vii  602790  Move  to  Contact  591811  Move  Tactically 


V21  -  H59:  move  to  Check  Point  Xray 
Expected  Result  Result  of  Movement  to  Contact: 


D-3 


Item  Unit  Location  Mission  Objective  Tasks 

V1.16  All  Units  605788  Move  to  Contact  591811  Move  Tactically 


All  Units  -  H59:  move  to  Check  Point  Xray 
Expected  Result  Result  of  Movement  to  Contact: 


Item  Unit  Location  Mission  Objective  Tasks 

VI. 17  W46  591811  Move  to  Contact  601813  Exe.  Travel  Ovenvatch 


w46  -  H59:  Move  to  Obj.  Delta 
Expected  Result  Result  of  Travel  Overwatch: 


Item  Unit  Location  Mission  Objective  Tasks 

VI. 19  All  Units  605788  Move  to  Contact  603815  Move  Tactically 


All  Units  -  H59:  Hold  Fire  and  Halt 
Expected  Result  Result  of  Movement  to  Contact: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .20  W46  599814  Move  to  Contact  599814  Perform  attack  by  fire 


W46  -  H59:  ACTION(  ):  (Engage  Enemy  at  603815) 
Expected  Result  Result  of  engagement: 


D-4 


Item  Unit  Location  Mission  Objective  Tasks 

V1.21  X72  596813  Move  to  Contact  603815  Occupy  TOW  Fire  Position 


X72  -  H59:  ACTION  (  ):  (set  up  a  firing  position  at  60381 6  ?) 
Expected  Result  Result  of  occupy  position: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .22  W46  599814  Move  to  Contact  603815  Conduct  Fire  and  Movement 


W46  -  H59:  Assault  Enemy  Ppsition 
Expected  Result  Result  of  Fire  and  Movement: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .23  All  Units  605788  Move  to  Contact  596824  Move  Tactically 


All  Units  -  H59:  Move  to  Check  Point  Yankee 
Expected  Result  Result  of  Movement  to  Contact: 


VIGNETTE  1:  PHASE  LINE  BLACK,  TO  PHASE  LINE  RED 
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OnOrdenSETUP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

V1.26  Red  Force  Enemy  Pit.  of  Tanks  561865  Hold  Tank  Pit. 


Weapons  Free;  Red  Force  Tanks  Location  561856  move  to  578846 

Expected  Result 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .28  V21  &W46  585635  Movement  to  567844  Move  Tactically 

Contact 

V21  &  W46  -  H59:  Move  to  Objective  Bravo 
Expected  Result  Result  of  Movement  to  Contact: 


Item  Unit  Location  Mission  Objective  Tasks 

VI  .29  V21  &  W46  579840  Movement  to  588837  Withdraw  under  enemy 

Contact  pressure 

Move  from  579840  to  582837 

Expected  Result  Result  of  Movement  to  Contact 


Shipboard  CAS 
CAS  at  584856  Inf. 
RCAS  at  576846  Tanks 


D-6 


Item  Unit  Location  Mission  Objective  Tasks 

V1 .32  X72  583838  Move  to  Contact  573849  Occupy  Fire.  Position 


X72  -  H59:  Clear  in  Zone  and  move  to  Bn  Obj.  Charlie 
Expected  Result  Result  of  Movement  to  Contact: 


Item  Unit  Location  Mission  Objective  Tasks 

V1 .33  C45  583838  Move  to  588863  Occupy  Fire  Pos. 

Contact 

C45  -  H59:  Clear  in  Zone  and  move  to  LF  Obj.  Golf 
Expected  Result  Result  of  Movement  to  Contact: 


SETUP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

vil  Red  Force  Enemy  Pit.  BMP/DI  862048  Hold  BMP/DI 


Red  Force  Location  862048,  BMP/DI 

Expected  Result 
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SETUP 


V2.3  Red  Force  Enemy 


Expected  Result 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

Enemy 

Pit.  Tanks 

875995 

moving 

BMP/DI 

Red  Force  at  895995  to  Ambush  Blue  at  875990 

SET  UP 


V2.4  Red  Force  Enemy 


Expected  Result 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

Enemy 

Pit.  Tanks 

902918 

Moving 

Tanks  Pit. 

Red  Force  Tanks  at  902918 

SETUP 


V2.5  Red  Force  Enemy 


Expected  Result 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

Enemy 

Pit.  BMP/DI 

935965 

Moving 

BMP/DI 

Red  Force  Mech  Inf.  @  935965 

SETUP 


V2.6  Red  Force  I  Enemy 


Expected  Result 


Size: 


Squad 


Location 


939975 


Red  Force  Inf.  @  939975  w/  Bunker 


Activity 


Defend 


Type  of  Unit 


Inf.  Squad 


SETUP 


V2.7  Red  Force  Enemy 


Expected  Result 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

Enemy 

Pit.  BMP/DI 

815106 

Ambush 

BMP/DI 

Red  Force  Location  815106:  Inf.  &  BMP 

D-8 


SETUP 


Item 

Unit 

Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

V2.8 

Red  Force 

Enemy 

Pit.  BMP/DI 

895995 

Ambush 

BMP/DI 

r 

Red  Force  Location  895995  Inf.  &  BMP 

Expected  Result 


SETUP 


Item 

Unit 

V2.9 

AAD 

Expected  Result 


SETUP 


Item  Unit 


V2.10  Blue  Force 


Expected  Result 


Unit 


V2.11  V21 


Expected  Result 


Intell.  Msg. 


lea.  ZSU  23-4,  AAD  System 


Size: 

Location 

lea.  ZSU 

23-4 

907966 

Activity 


Type  of  Unit 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

MAGTF 

Co.  (+) 

781159 

Hold 

Mech  Co. 

USMC  MAGTF  @  781159 

Location 

Mission 

Objective 

Tasks 

781159 

Move  to 
Contact 

787164 

Perform  Route  Recon. 

V21  -  H59  move  to  the  LCD 

Item  Unit 


V2.12  All  Units 


Expected  Result 


Location 


781159 


Mission 


Move  to 
Contact 


Objective 


799115 


All  Units  -  H59  Move  to  PL  Yellow 


Result  of  Movement  to  Contact 


Tasks 


Move  Tactically 


D-9 


Gn  Order;  SET  UP 


Item  Unit 


V2.13 


Expected  Result 


Intell.  Msg.  Size; 


Location 


815106 


Weapons  Free  for  Red  Force  @  815106 


Activity  Type  of  Unit 


Item  Unit 


V2.14  All  Units 


Expected  Result 


Location 


800115 


Mission 


Move  to 
Contact 


Objective 


799115 


All  Units -H59  Hold  &  Halt 


Result  of  Movement  to  Contact 


Tasks 


Move  Tactically 


Item  Unit 


V2.15  W46 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

802110 

Move  to 
Contact 

812114 

Perform  attack  by  fire 

W46  -  H59  Move,  to  812114  Engage  Suspected  Enemy  at  815106 

Result  of  Movement  to  Contact  &  Engagemeni 

t: 

Item  Unit 


X72 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

802109 

Move  to 
Contact 

805115 

Occupy  TOW  Fire  Position 

X72  -  H59  set  up  a  firing  position  at  805115,  &  Engage  the  Enemy 

Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V2.17 

W46 

812114 

Move  to 
Contact 

815105 

Conduct  Fire  and  Movement 

W46  -  H59  Destroy  Enemy  Position 

Expected  Result 
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VIGNETTE  2:  PHASE  LINE  YELLOW,  TO  PHASE  LINE  ORANGE 


Item  Unit  Location  Mission  Objective  Tasks 

V2.19  V21  850085  Move  to  878090  Move  Tacticaiiy 

Contact 

V21  -  H59  Estabiish  Blocking  Position  at  878090 

Expected  Result 
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VIGNETTE  3:  PHASE  LINE  ORANGE,  TO  PHASE  LINE  GREEN 


Gn  Order  SET  UP 


Item  Unit 


V3.1  Tm  Taurus 


Expected  Result 


Location 


835087 


Mission 


Objective  Tasks 


Helo  Assault  LZ  Hawk  disembark  Fr.  AAV 


Team.  Taurus  disembark  from  the  AAV  @  LZ  Penguin:  835087 


Result  of  Debark: 


Item  Unit 


V3.4  V21 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

878090 

Move  to 
Contact 

878001 

Move  Tactically 

V21  -  H59:  Move  to  Obj.  Zulu 

Item  Unit 


V3.5  All  Units 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

853085 

Move  to 
Contact 

870004 

Move  Tactically 

All  units  -  H59:  follow  in  trace  of  V21  to  Phase  Line  Green 

On  Order:  SET  UP 


Expected  Result 


Intell.  Msg.  Size: 


Location 


862048 


Weapons  Free  for  Red  Force  @  862048 


Activity  Type  of  Unit 


Item  Unit 


V3.7  V21 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

867055 

Movement  to 
Contact 

867064 

Withdraw  under  enemy 
pressure 

Move  from  867055  to  874064 

Item  Unit  Location  Mission  Objective  Tasks 

V3.9  W46  865070  Movement  to  877  Perform  Attack  by  Fire 

Contact 

W46  -  H59  move  to  hill  2419  and  Suppress  Enemy  Ambush 

Expected  Result 


Item  Unit  Location  Mission  Objective  Tasks 

V3.10  X72  863073  Movement  to  871063  Occupy  Fire  Pos. 

Contact 

X72  -  H59  move  to  hill  2432,  Suppress  Enemy  Ambush, 

Expected  Result 


Item  Unit  Location  Mission  Objective  Tasks 

V3.12  W46  877  Move  to  862048  Conduct  Fire  and  Movement 

Contact 

W46  -  H59  Assault  Enemy  Position 

Expected  Result 


D-13 


On  Order:  SET  UP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

V3.13  Red  Force  Enemy  BMP/DI  875995  moving  BMP/DI 


Weapons  Free;  Red  Force  at  895995  to  Ambush  Blue  at  875990 

Expected  Result 


On  Order:  SET  UP 

Item  Unit  Intell.  Size:  Location  Activity  Type  of  Unit 

V3.14  Red  Force  Enemy  BMP/DI  902918  Moving  Tanks  Pit. 


Weapons  Free;  Red  Force  Tanks  at  902918  move  to  882965 

Expected  Result 


Oh  Order:  SET  UP  - 

Item  Unit  Intel!.  Size:  Location  Activity  Type  of  Unit 

V3.15  Red  Force  Enemy  BMP/DI  935965  Moving  BMP/DI 


Weapons  Free;  Red  Force  Mech  Inf.  moves  from  935965  to  893969 

Expected  Result 


D-14 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.18 

All  Units 

865063 

Move  to 
Contact 

PI.  Green 

Move  Tactically 

Ail  Units  move  to  Phase  Line  Green 

Expected  Result 


VIGNETTE  3:  PHASE  LINE  GREEN  TO  PHASE  LINE  RED 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.20 

V21 

878003 

Move  to 
Contact 

895950 

Move  Tactically 

V21  -  H59  move  from  870003  to  895950 

Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.21 

All  Units 

873020 

Move  to 
Contact 

PI.  Red 

Move  Tactically 

All  Units  move  to  Phase  Line  Red 

Expected  Result 


On  Order  SET  UP 


Item 


V3.22 


Location 


Mission 


Objective 


Tm.  Taurus  835087 


Helo  Assault  955965 


Tasks 


Perform  Helo.  Movement 


Expected  Result 


Helo  Assault  from  LZ  Penguin  835087,  to  LZ  Hawk  955965 
Via  the  following  Way  Points 

1 .  LZ  Penguin  @  835087 

2.  949089 

3.  967039 

4.  987960 

5.  LZ  Hawk  @  955965 


OnT:)rder:SETttP 


Expected  Result 


Intell. 

Size: 

Location 

Activity 

Type  of  Unit 

Enemy 

Pit.  BMP/DI 

892969 

Hold 

BMP/DI 

Weapons  Free;  for  Red  Force  @  892969 

Expected  Result 


Location 

Mission 

Objective 

Tasks 

877980 

Movement  to 
Contact 

868982 

Withdraw  under  enemy 
pressure 

Move  from  877980  to  868982 

Item  Unit 


V3.25  All  Units 


Expected  Result 


Location 

Mission 

Objective 

Tasks 

874994 

Move  to 
Contact 

874994 

Screen  Operations 

All  Units  -  H59  Hold  Fire,  Halt 

D-16 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.26 

W46 

874988 

Movement  to 
Contact 

874988 

Perform  Attack  by  Fire 

W46  -  H59  Suppress  Enemy  Ambush  In  Place 

Expected  Result 


On  Order:  SET  UP 

Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.27 

Tm  Taurus 

LZHawk 

955965 

Seize  Obj  C 
@  939977 

ObjC 

939977 

USMC  Attack 

Move  fr.  LZ  Hawk  to  CP  ORO  @  949962 

Mortar  SET  UP  @  CP  ORO 

Pit.  via  USMC  Attack/Single  Envelopment  Obj  C 

Move  to  CP  6e6  @  936966 

Move  to  CP  6f6  @  932962 


Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.28 

X72 

873992 

Movement  to 
Contact 

873992 

Occupy  Fire  Pos. 

X72  -  H59  Engage  Enemy  @  892969 

Expected  Result 


On  Order:  SET  UP 


Item 

Unit 

V3.29 

RCAS/CAS 

Location 


Mission 


RCAS  &  CAS 


Objective 


Tasks 


RCAS  &  CAS 


IP  Gypsum  Ridge 
RCAS  at  895995  Inf. 
CAS  at  882965  Tanks 


Expected  Result 
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Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.30 

C45 

872996 

Move  to 
Contact 

888982 

Assault  an  Enemy  Pos. 

1 

C45  -  H59  Destroy  Enemy  Infantry  Firing  Position,  @  892969 

Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.31 

W46 

892969 

Move  to 
Contact 

882965 

Assault  an  Enemy  Pos. 

W46  -  H59  Assault  Enemy  Position  @  89296J 

),  and  Secure  882968 

Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.32 

V21 

868982 

Move  to 
Contact 

885946 

Move  Tactically 

L _ _ 

V21  -  H59  move  to  PL  Red 

Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.33 

All  Units 

870990 

Move  to 
Contact 

PI.  Red 

Move  Tactically 

All  Units  move  to  Phase  Line  Red 

Expected  Result 


Item 

Unit 

Location 

Mission 

Objective 

Tasks 

V3.34 

X72&G14 

874980 

Move  to 
Contact 

932962 

Move  Tactically 

X72  &  G14  -  H59  move  to  Obj  Foxtrot 

Expected  Result 
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PHASE  5.  PHASE  LINE  RED  TO  BATTALION  OBJECTIVE  H 

Item  Unit  Location  Mission  Objective  Tasks 

V3.36  V21  895950  Movement  to  891914  Move  Tactically 

contact 

V21  -  H59  move  to  Obj  Quebec 

Expected  Result 


Item  Unit  Location  Mission  Objective  Tasks 

V3.38  G14  874990  Movement  to  880928  Move  Tactically 

contact 

G14  -  H59  Seize  Obj  Hotel 

Expected  Result 
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APPENDIX  E 

AIR  FORCES  SYNTHETIC  FORCES  SUPPORTING  DATA 


WISSARD  CONFIGURATIONS 

The  specific  hardware  configuration  utilized  at  WISSARD  for  the  AFSF  and  AirSAF  consisted  of: 

1 .  Blue  Air:  SGI  R4000  pocket  system  running  WISSARD  Air  SF; 

2.  Red  Air:  SGI  R4000  pocket  system  running  WISSARD  Air  SF; 

3.  Ground  Targets:  SGI  R4000  pocket  system  running  MCSF; 

4.  Data  Logger:  SGI  R4000; 

5.  Plan  View  Display:  SGI  R3000  (NRaD  2-D  PVD  version); 

6.  Ordnance  Server:  SGI  R3000  switched  to  SGI  R4400; 

7.  IFOR  FWA:  2  x  SGI  R4400; 

8.  IFOR  RWA:  2  X  SGI  R4400; 

9.  AFSF:  SGI  R4400; 

10.  AFSF:  SUN  Sparc  20. 
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APPENDIX  F 

CONFIGURATION  DIAGRAMS 


The  configuration  diagrams  are  provided  in  the  file  called:  DCA_AppendixF,  which  is  located  in 
the  STOW_REPORTS  directory  on  froggie.  There  are  thirteen  diagrams  in  this  file  with  page  num¬ 
bers  115  through  127. 
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1 0  workstation 
with  one  being 
used  as  Ordan 


Figure  F-1.  Classified  electrical  and  fiber-optic  connectivity  at  NRaD  during  Day  4  for  ED-1 . 


Figure  F-2.  Classified  hardware  configuration  at  IDA  during  Day  4  for  ED-1 . 


igure  F-3.  Configuration  al 


Large  Screen  Dispta 


Figure  F-4.  Configuration  at  WISSARD  during  Day  4  for  ED-1 . 
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F-9 


Figure  F-8.  Unclassified  hardware  configuration  at  IDA  for  ED-1 . 
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. . . . .  . - . . . '  #2:  30  May  1995 

Figure  F-9.  Unclassified  hardware  configuration  at  NRLfor  ED-1. 


Figure  F-10.  Unclassified  hardware  configuration  at  TEC  for  ED-1 


SGI  Workstation 


Figure  F-11.  Unclassified  hardware  configuration  at  ARL:UTfor  ED-1. 


DARPA  10th  Floor 
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Figure  F-12.  Unclassified  hardware  configuration  at  DARPA  for  ED-1 


1 


>1 
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